PCI SAQ D
Oversikt over hvilke tiltak vi gjør i Cardholder Data Environment (som er definert til å være okkupasjon) for å møte kravene i PCI SAQ D 3.2.1, sist utfylt 2021-01-??.
Punkt | Respons | Kommentar | Sjekk |
---|---|---|---|
1.1.1 | ? | Is there a formal process for approving and testing all network connections and changes to the firewall and router configurations? | |
1.1.2a | ? | Is there a current network diagram that documents all connections between the cardholder data environment and other networks, including any wireless networks? | |
1.1.2b | ? | Is there a process to ensure the diagram is kept current? | |
1.1.3a | ? | Is there a current diagram that shows all cardholder data flows across systems and networks? | |
1.1.3b | ? | Is there a process to ensure the diagram is kept current? | |
1.1.4a | ? | Is a firewall required and implemented at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone? | |
1.1.4b | ? | Is the current network diagram consistent with the firewall configuration standards? | |
1.1.5 | ? | Are groups, roles, and responsibilities for logical management of network components assigned and documented in the firewall and router configuration standards? | |
1.1.6a | ? | Do firewall and router configuration standards include a documented list of services, protocols, and ports, including business justification and approval for each? | |
1.1.6b | ? | Are all insecure services, protocols, and ports identified, and are security features documented and implemented for each identified service? | |
1.1.7a | ? | Do firewall and router configuration standards require review of firewall and router rule sets at least every six months? | |
1.1.7b | ? | Are firewall and router rule sets reviewed at least every six months? | |
1.2.1 a-b | Y | iptables lokalt på okkupasjon; skal kun ha tilgang til security.d.o, debian.s.n, clamav-oppdatering, Swedbank Pay, Postgres på cirkus, HTTPS og SSH fra kjente steder, samt ICMP | /usr/local/sbin/iptables-setup.sh |
1.2.2 | ? | Are router configuration files secured from unauthorized access and synchronized–for example, the running (or active) configuration matches the start-up configuration (used when machines are booted)? | |
1.2.3 | Y | Se 1.2.1; ingen trafikk til okkupasjon (bortsett fra HTTPS) er tilgjengelig fra WLANet | |
1.3.1 | ? | Is a DMZ implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports? | |
1.3.2 | ? | Is inbound Internet traffic limited to IP addresses within the DMZ? | |
1.3.3 | ? | Are anti-spoofing measures implemented to detect and block forged sourced IP addresses from entering the network? (For example, block traffic originating from the internet with an internal address.) | |
1.3.4 | Y | Se punkt 1.2.1 | |
1.3.5 | Y | Se punkt 1.2.1 | |
1.3.6 | ? | Are system components that store cardholder data (such as a database) placed in an internal network zone, segregated from the DMZ and other untrusted networks? | |
1.3.7a | ? | Are methods in place to prevent the disclosure of private IP addresses and routing information to the Internet? | |
1.3.7b | ? | Is any disclosure of private IP addresses and routing information to external entities authorized? | |
1.4a | ? | Is personal firewall software (or equilvalent functionality) installed and active on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE? | |
1.4b | ? | Is the personal firewall software (or equilvalent functionality) configured to specific configuration settings, actively running, and not alterable by users of mobile and/or employee-owned devices? | |
1.5 | ? | Are security policies and operational procedures for managing firewalls: Documented, In use, Known to all affected parties? | |
2.1a | Y | Det er ikke noe nettverksutstyr mellom CDE og Internett (siden brannveggen er på okkupasjon selv). Uansett bytter vi alltid defaultpassord på utstyr. | |
2.1b | Y | Se 2.1a | |
2.1.1 a-e | NA | Det er ingen WLAN koblet til okkupasjon (folk kan kjøpe billetter fra WLAN, men da altså bare over HTTPS) | |
2.2a | Y | okkupasjon er konfigurert til å kun tillate SSH2, kun sterk kryptografi i HTTPS, SSL-tilkoblinger til cirkus, pakkeinstallasjon er alltid signert i Debian | /etc/ssh/sshd_config, /etc/apache2/apache2.conf, /etc/apache2/mods-enabled/ssl.conf |
2.2b | Y | Unattended-upgrades er installert. Når kritiske svakheter offentliggjøres som ikke er i apt enda, gjør vi en vurdering på å installere dem manuelt | /etc/apt/apt.conf.d/50unattended-upgrades |
2.2c | Y | Når vi en sjelden gang reinstallerer okkupasjon, kopierer vi relevant konfigurasjon fra forrige installasjon | |
2.2d | Y | Vi har ingen unødvendige konti. okkupasjon har kun én oppgave. Kun nødvendige tjenester kjører. okkupasjon kjører ingen tjenester som krever ekstra sikkerhet. Det er liten eller ingen mulighet til å misbruke okkupasjon, blant annet fordi tilgang til maskinen er svært begrenset (merk at root login og logins med tomt passord avvises av sshd). | /etc/passwd, /etc/shadow, /etc/ssh/sshd_config |
2.2.1a | Y | okkupasjon har kun én oppgave. | |
2.2.1b | NA | okkupasjon er ikke virtualisert og er ikke vert for virtuelle gjester | |
2.2.2a | Y | Se punkt 2.2a og 2.2d | systemctl, /etc/cron.*, /etc/rc.local |
2.2.2b | Y | okkupasjon har ingen usikre tjenester | |
2.2.3 | Y | Se 2.2.2b | |
2.2.4a | Y | Stillingen som tjeneransvarlig krever gode kunnskaper om å sikre maskiner og tjenester | |
2.2.4b | Y | Standardkonfigurasjonen hos Debian, og de endringene vi bruker, regnes å ha adekvat sikkerhet | |
2.2.4c | Y | Se 2.2a | |
2.2.5a | Y | Det kjører ingen unødvendige tjenester på okkupasjon, se også 2.2.4b | |
2.2.5b | Y | Wikien dokumenterer okkupasjon-oppsett. Se også 2.2a | |
2.2.5c | Y | Ja, se også 2.2d | |
2.3a | Y | okkupasjon tillater kun SSH2. Ingenting på okkupasjon aksepterer passord eller kommandoer utenfor krypterte kanaler. | |
2.3b | Y | okkupasjon kjører ikke telnet eller andre usikre tjenester | |
2.3c | NA | Vi har ingen web-baserte admingrensesnitt på okkupasjon | |
2.3d | Y | SSH2 er industristandard. Både host- og user-nøkler er > 2048 bit. | |
2.4a | ? | Is an inventory maintained for systems components that are in scope for PCI DSS, including a list of hardware and software components and a description of function/use for each? | |
2.4b | ? | Is the documented inventory kept current? | |
2.5 | Y | okkupasjon har ingen vendor defaults. Oppsettet er dokumentert i wikien. Kun tjeneransvarlig, Billigansvarlig, gjengsjef og personell som er spesielt egnet og behov har tilgang til okkupasjon. Vi forventer tilstrekkelige kunnskaper om sikker konfigurering av alle disse. Det holdes kurs om oppsettet til nytt personell. | |
3.2c | Y | Vi lagrer aldri sensitive autentiseringsdata ved pålogging eller bruk av okkupasjon | |
3.2.1 | NA | Vi har aldri kortet fysisk, og kan derfor aldri lagre innholdet på magnetstripene | |
3.2.2 | Y | Koden lagrer aldri, under noen omstendighet (heller ikke under feilsøking) CVC2 | |
3.2.3 | NA | Vi får aldri PIN, dermed er det aldri mulighet for å lagre den | |
3.3 | Y | Trunkert PAN (siste fire siffer) lagres i databasen. Vi lagrer aldri full PAN. Personell med tilgang til å søke opp ordre kan se trunkert PAN, som er nødvendig for å bekrefte kundens identitet ved spørsmål om eierskap til billetter. Personell som har adgang til å se dette kurses alltid før de får tilgang. Det er advarsler i brukergrensesnittet for bruk av trunkert PAN. | |
3.4 | Y | Som nevnt i 3.3 bruker vi trunkert PAN. | |
3.4.1a | ? | Is logical access to encrypted file systems managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials)? | |
3.4.1b | ? | Are cryptographic keys stored securely (for example, stored on removable media that is adequately protected with strong access controls)? | |
3.4.1c | NA | Vi lagrer ikke kortholderdata på eksterne disker. | |
3.6.1 | ? | Do cryptographic key procedures include the generation of strong cryptographic keys? | |
3.6.2 | ? | Do cryptographic key procedures include secure cryptographic key distribution? | |
3.6.3 | ? | Do cryptographic key procedures include secure cryptographic key storage? | |
3.6.4 | ? | Do cryptographic key procedures include cryptographic key changes for keys that have reached the end of their defined cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57)? | |
3.6.5a | ? | Do cryptographic key procedures include retirement or replacement (for example, archiving, destruction, and/or revocation) of cryptographic keys when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key)? | |
3.6.5.b | ? | Do cryptographic key procedures include replacement of known or suspected compromised keys? | |
3.6.5.c | ? | If retired or replaced cryptographic keys are retained, are these keys only used for decryption/verification purposes, and not used for encryption operations? | |
3.6.6 | ? | If manual clear-text key-management operations are used, do cryptographic key procedures include split knowledge and dual control of cryptographic keys as follows: Do split knowledge procedures require that key components are under the control of at least two people who only have knowledge of their own key components? AND Do dual control procedures require that at least two people are required to perform any key management operations and no one person has access to the authentication materials (for example, passwords or keys) of another? | |
3.6.7 | ? | Do cryptographic key procedures include the prevention of unauthorized substitution of cryptographic keys? | |
3.6.8 | ? | Are cryptographic key custodians required to formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities? | |
3.7 | ? | Are security policies and operational procedures for protecting stored cardholder data: Documented, In use and Known to all affected parties? | |
4.1a | Y | Kortdata sendes over det åpne Internett fra kunden til oss, og så fra oss til Swedbank Pay. Tilkoblingene er alltid over HTTPS (TLS) | curl -v http://samfundet.no |
4.1b | Y | Ingen systemer på okkupasjon er konfigurert til å akseptere selvsignerte eller usignerte sertifikater. Vi bruker Debians standard CA-liste når vi validerer Swedbank Pays sertifikat. | |
4.1c | Y | Ingen systemer på okkupasjon er konfigurert til å bruke usikre utgaver av protokoller. Se også 1.2.1a | |
4.1d | Y | Inngående HTTPS støtter kun sterk kryptografi med TLS, setter HSTS til langt frem i tid. Liste over støttede sifre, hashfunksjoner og TLS/SSL-utgaver er begrenset, og i tråd med eller strengere enn gjeldende industristandard | crikus:/etc/varnish/default.vcl, /etc/apache2/apache2.conf |
4.1e | Y | okkupasjon tar kun imot kortdata over HTTPS, og sender dem kun til Swedbank Pay over HTTPS. (For sikkerhets skyld er alt annet brannvegget bort, se 1.2.1a.) | |
4.1.1 | NA | Vi sender aldri kortdata over WLAN, og CDEet har uansett ikke noe WLAN | |
4.2a | NA | Vi sender aldri PAN over noen som helst meldingsprotokoll. | |
4.2b | Y | Vi ber aldri brukere om å sende kortnummer (PAN) over noen messaging-protokoll. Brukerstøttepersonell er kjent med dette, og kurses før de får tilgang. | |
4.3 | ? | Are security policies and operational procedures for encrypting transmissions of cardholder data: Documented, In use and Known to all affected parties? | |
5.1 | Y | okkupasjon kjører clamav og rkhunter nattlig. Debian er uansett en plattform med kjente, relevante virus. | |
5.1.1 | NA with CCW | clamav og rkhunter rapporterer om virus og annen malware, men kan ikke fjerne dem. Fjerning må skje av personell. | |
5.1.2 | Y | Vi vurderer løpende og daglig nye trusler, på IRC og i møter. Tjeneransvarlig følger med på debian-security-annonce | |
5.2a | Y | clamav har ukentlig oppdatering | |
5.2b | Y | Se 5.1 | |
5.2c | Y | Både clamav og rkhunter logger til syslog | |
5.3 | Y | clamav kjører med cron. Kun root kan slå den av eller på. Ingen var våre rutiner krever at antivirus slås av. | |
6.1 | Y | Det gjelder generelt at alle trusler vi finner regnes som seriøse. Kilder for informasjon er primært Debian Security Advisories, men følger også med på vanlige informasjonskilder i industrien. Billig-ansvarlig og tjeneransvarlig er ansvarlige for å vurdere risiko for sårbarheter. | |
6.2a | Y | Sikkerhetsoppdateringer fra Debian skal installeres automatisk med unattended-upgrades. Tjeneransvarlig følger med på debian-security-announce for å vurdere om vi må støvle okkupasjon for kjerneoppdateringer | |
6.2b | Y | Se 6.2a. Det opprettes også sak i saksbehandlingssystemet når kjerneoppdateringer er tilgjengelig, slik at vi kan spore hvor lang tid det har gått. Ikke-støvlingskrevende oppdateringer installeres som nevnt automatisk med apt, og monitoreres med munin | |
6.3a-b | Y | Utvikling av Billig skjer i henhold til PCI DSS-krav og gjennom code review fokuseres det på informasjonssikkerhet og industristandarder. | |
6.3.1 | Y | Vi utvikler ikke i produksjon og det er derfor ingen fare for at utviklingsbrukere/-passord eller liknende henger igjen. Sluttproduktet har heller ingen brukere. | |
6.3.2 | Y | Vi benytter oss av code review. | |
6.4.1a | Y | Vi bedriver hverken utviklingsarbeid eller testarbeid i produksjon | |
6.4.1b | Y | Tilgang til okkupasjon er strengt begrenset. | |
6.4.2 | ? | Is there separation of duties between personnel assigned to the development/test environments and those assigned to the production environment? | |
6.4.3 | Y | Vi bruker aldri ekte data i test- eller utviklingssammenheng | |
6.4.4 | Y | Vi har ingen testkontoer eller -data på okkupasjon. | |
6.4.5a | NA | Are change-control procedures documented and require the following? Documentation of impact, Documented change control approval by authorized parties, Functionality testing to verify that the change does not adversely impact the security of the system or Back-out procedures | Foreløpig svar: In the event of larger changes to the system, all possible effects of the change are taken into account and discussed within the team. We employ OpenVAS to scan for vulnerabilities. By using git for version control, restoring the system to an earlier state is a non-issue. |
6.4.5.1-3 | NA | Se 6.4.5a | |
6.4.5.4 | Y | Vi bruker versjonskontroll og kan derfor enkelt rulle tilbake endringer. | |
6.4.6 | Y | Beskrevet i sikkerhetspolicy | |
6.5a | ? | Do software-development processes address common coding vulnerabilities? | |
6.5b | ? | Are developers trained at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. | |
6.5.1 | Y? | Do coding techniques address injection flaws, particularly SQL injection? | |
6.5.2 | ? | Do coding techniques address buffer overflow vulnerabilities? | |
6.5.3 | ? | Do coding techniques address insecure cryptographic storage? | |
6.5.4 | ? | Do coding techniques address insecure communications? | |
6.5.5 | ? | Do coding techniques address improper error handling? | |
6.5.6 | ? | Do coding techniques address all "high risk" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1)? | |
6.5.7 | ? | Do coding techniques address cross-site scripting (XSS) vulnerabilities? | |
6.5.8 | ? | Do coding techniques address improper access control such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions? | |
6.5.9 | ? | Do coding techniques address cross-site request forgery (CSRF)? | |
6.5.10 | ? | Do coding techniques address broken authentication and session management? | |
6.6 | ? | For public-facing web applications, are new threats and vulnerabilities addressed on an ongoing basis, and are these applications protected against known attacks by applying either of the following methods? 1. Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, or 2. Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) as follows: Is situated in front of public-facing web applications to detect and prevent web-based attacks. | |
7.1.2 | Y | Det er bare personell med særs behov som har tilgang til okkupasjon | |
7.1.3 | Y | Se 7.1.2 | |
8.1.1 | Y | Ved bruk av brukernavn | |
8.1.5a | NA | Ingen eksterne har aksess til okkupasjon. | |
8.1.5b | NA | Se 8.1.5a | |
8.1.6 | Y | Implementert med pam_tally2 | /etc/pam.d/su |
8.1.7 | Y | Cf. 8.1.6 | |
8.1.8 | Y | Implementert med ClientAliveInterval | /etc/ssh/sshd_config |
8.2 | Y | Gjort i form av 2-faktor login (ssh-nøkkel + passord) | |
8.2.3(a) | Y | Implementert med pam_cracklib | /etc/pam.d/common-password |
8.2.4(a) | Y | Implementert i /etc/login.defs linje 160-162. Merk at vi har økt passord-kompleksitet for å kunne endre passord kun hvert år i stedet for hver tredje måned. | /etc/login.defs |
8.2.5(a) | Y | Implementert med pam_unix | /etc/pam.d/common-password |
8.2.6 | NA | Passord lages av brukeren selv rett i okkupasjon, eller ved at brukeren hasher passordet sitt og får det lagt inn i /etc/passwd. Vi bruker ingen midlertidige passord | |
8.3.1 | Y | All administrativ tilgang til okkupasjon gjøres over SSH2, med tofaktor: Personlig passord, samt personlig SSH-nøkkel (som i sin tur skal oppbevares kryptert på énbrukersystemer og være beskyttet med passord) | |
8.3.2 | Y | Se 8.3.1 | |
8.4a | Y | Relevant personell kurses, se Billig sikkerhetspolicy | |
8.4b | Y | Se 8.4a | |
8.5 | Y | Det eksisterer ingen fellesbrukere | /etc/passwd, /etc/shadow |
8.6 | Y | Vi har ingen felles Yubikey-er o.l. | |
8.7a-c | NA | Ikke relevant ettersom vi ikke lagrer kortholderdata. | |
8.8 | Y | Se Billig sikkerhetspolicy | |
9.1 | Y | Gjort i form av både kortlåssystem og nøkkellås. | |
9.1.1 | Y | Vi bruker kortlåsen for å begrense tilgang, samt for å spore hvem som har kortet seg inn. Vi går aldri gjennom dataen, og vi korrelerer heller ikke dataen. Vi lagrer dataen i 90 dager, som begrenset av norsk lov. | |
9.1.2 | Y | okkupasjon er i ett eget lukkede lokale med begrenset tilgang. Det er ingen fysiske nettplugger tilgjengelig i CDEet (siden det er begrenset til okkupasjon) | |
9.1.3 | Y | Se 9.1.2 | |
9.2a-c | NA | Kun ITK samt enkelte av husets ansatte har tilgang til Anette, hvilket betyr at besøkende kun har tilgang under oppsyn av autorisert personnel. Gitt det lave antallet folk med tilgang er det heller ikke nødvendig med skilt for å identifisere besøkende. | |
9.3 | Se 9.2 | ||
9.5 | NA | Vi distribuerer aldri fysiske media fra okkupasjon, og vi har aldri media med cardholder data | |
9.6a | NA | Se 9.5 | |
9.6.1-3 | NA | Se 9.5 | |
9.7 | NA | Se 9.5 | |
9.8a | NA | Se 9.5 | |
9.8.1a | NA | Se 9.5 | |
9.8.1b | NA | Se 9.5 | |
9.9a-c | NA | Vi har ingen enheter som er i kontakt med kortet. | |
9.9.1a-c | NA | Se 9.9a-c | |
9.9.2a-b | NA | Se 9.9a-c | |
9.9.3a-b | NA | Se 9.9a-c | |
10.2.1 | NA | Vi lagrer ikke kortholderdata. | |
10.2.2 | Y | Det blir lagret hvilke kommandoer en kjører, både med/uten sudo. sudo logger til auth.log, kommandoer kjørt direkte som root i roots .bash_history | |
10.2.3 | ? | Is access to all audit trails logged? | |
10.2.4 | Y | Vi logger alle påloggingsforsøk med syslog. | /etc/ssh/sshd_config |
10.2.5 | Y | Vi logger alt som gjøres av root. Endringer i /etc lagres uansett med etckeeper | |
10.2.6 | Initialization, stopping, or pausing of the audit logs? | ||
10.3.1 | Y | Identifisering og tilleggsinfo (tidspunkt, hvem, fra hvor, etc) logges til /var/log/auth.log | /var/log/auth.log |
10.3.2 | Y | Se 10.3.1 | |
10.3.3 | Y | Se 10.3.1 | |
10.3.4 | Y | Se 10.3.1 | |
10.3.5 | Y | Se 10.3.1 | |
10.3.6 | Y | Se 10.3.1 | |
10.4 | Y | okkupasjon har NTP fra ntp-kina | |
10.4.1a | ? | Do only designated central time server(s) receive time signals from external sources, and are time signals from external sources based on International Atomic Time or UTC? | |
10.4.1b | NA | Vi har ikke flere tidsservere koblet til okkupasjon. | |
10.4.1c | ? | Do systems receive time only from designated central time server(s)? | |
10.4.2a | ? | Is access to time data restricted to only personnel with a business need to access time data? | |
10.4.2b | ? | Are changes to time settings on critical systems logged, monitored, and reviewed? | |
10.4.3 | ? | Are time settings received from specific, industry-accepted time sources? (This is to prevent a malicious individual from changing the clock). | |
10.5.1 | Y | Kun ITK får logchecker-mail fra okkupasjon | |
10.5.2 | ? | Are audit trail files protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation? | |
10.5.3 | Y | okkupasjon sikkerhetskopieres til kolje daglig | |
10.5.4 | ? | Are logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) written onto a secure, centralized, internal log server or media? | |
10.5.5 | ? | Is file-integrity monitoring or change-detection software used on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert)? | |
10.6.1a | ? | Are written policies and procedures defined for reviewing the following at least daily, either manually or via log tools? All security events, Logs of all system components that store, process, or transmit CHD and/or SAD, Logs of all critical system components, Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) | |
10.6.1b | Y | okkupasjon kjører logcheck i server-modus, som sender epost om sikkerhetshendelser til billig-drift@samfundet.no | /etc/logcheck |
10.6.2b | Y | Se 10.6.1b | |
10.6.3b | Y | Anomalier sendes til billig-drift@samfundet.no, som blir gjennomgått fortløpende | |
10.7b | Y | logrotate tar vare på relevante logger (syslog, auth.log, apache-logger) i ett år, inkludert i backup. | /etc/logrotate.d |
10.7c | Y | Alle relevante logger er tilgjengelige i minst tre måneder på okkupasjon. | |
11.1a | NA | CDE består kun av én maskin, og det eksisterer dermed ikke noe CDE-nett å koble trådløsnett til | |
11.1b | NA | Se 11.1a | |
11.1c | NA | Se 11.1a | |
11.1d | NA | Se 11.1a | |
11.1.1 | NA | Se 11.1a | |
11.1.2a | NA | Se 11.1a | |
11.1.2b | NA | Se 11.1a | |
11.2.1a | Y | Kvartalvis skann med OpenVAS | |
11.2.1b | Y | Hvis en skann med OpenVAS gir score høyere enn 3.0, utbedres dette av serveransvarlig | |
11.2.1c | Y | Søk blir gjort av ITKere, som alle er kvalifiserte. | |
11.2.2a | Y | Trustkeeper er ASV, med månedlig scanning | |
11.2.2b | Y | Vi gjør tiltak frem til scanningen ikke lenger har sårbarheter høyere rating enn 4.0 | |
11.2.2c | Y | Se 11.2.2a | |
11.2.3a | Y | Vi endrer veldig sjelden oppsettet vårt. Når dette dog gjøres blir det gjort ekstraordinær ekstern scanning. | |
11.2.3b | Y | Vi gjør søk og endringer til det ikke oppdages flere feil. | |
11.2.3c | Y | Søk blir gjort av ITKere, som alle er kvalifiserte | |
11.3 | ? | Does the penetration-testing methodology include the following? Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115), Includes coverage for the entire CDE perimeter and critical systems, Includes testing from both inside and outside the network, Includes testing to validate any segmentation and scope-reduction controls, Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5, Defines network-layer penetration tests to include components that support network functions as well as operating systems, Includes review and consideration of threats and vulnerabilities experienced in the last 12 months, Specifies retention of penetration testing results and remediation activities results. | |
11.3.1a | ? | Is external penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)? | |
11.3.1b | ? | Are tests performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)? | |
11.3.2a | ? | Is internal penetration testing performed per the defined methodology, at least annually, and after any significant infrastructure or application changes to the environment (such as an operating system upgrade, a sub-network added to the environment, or an added web server)? | |
11.3.2b | ? | Are tests performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV)? | |
11.3.3 | ? | Are exploitable vulnerabilities found during penetration testing corrected, followed by repeated testing to verify the corrections? | |
11.3.4a | NA | Vi gjør ikke segmentering av nettet for CDEet | |
11.3.4b | NA | Se 11.3.4a | |
11.3.4c | Y | Gjennomført av Trustwave og OpenVAS. | |
11.4a | ? | Are intrusion-detection and/or intrusion-prevention techniques that detect and/or prevent intrusions into the network in place to monitor all traffic: At the perimeter of the cardholder data environment, and At critical points in the cardholder data environment. | |
11.4b | ? | Are intrusion-detection and/or intrusion-prevention techniques configured to alert personnel of suspected compromises? | |
11.4c | ? | Are all intrusion-detection and prevention engines, baselines, and signatures kept up-to-date? | |
11.5b | Y | rkhunter og etckeeper varsler over epost | |
11.5.1 | Y | Billigansvarlig og tjeneransvarlig har ansvar for å respondere på ukjente endringer. Se også Krisehåndtering. | |
12.1 | Y | Se Billig sikkerhetspolicy | |
12.1.1 | Y | Noden blir oppdatert, og blir gjenomgått av ny Billigansvarlig og gjengsjef, som er minst årlig. | |
12.2a | ? | Is an annual risk assessment process implemented that identifies critical assets, threats, and vulnerabilities, and results in a formal, documented analysis of risk? | |
12.2b | ? | Does the risk assessment process result in a formal risk assessment? | |
12.3.1 | Y | Tilgang til CDE gis på person-til-person-basis, og personene gjøres kjent med hvilke krav som gjelder for utstyret som brukes. Billig sikkerhetspolicy gjelder for slikt utstyr. | |
12.3.2 | Y | Se 12.3.1 | |
12.3.3 | Y | Listen over hvem som har tilgang til okkupasjon er listen over personlige brukere på boksen | |
12.3.4 | Y | RackOversikt lister alt som står i Anette. | |
12.3.5 | Y | Se 12.3.1 | |
12.3.6 | Y | All administrativ adgang til okkupasjon er begrenset til å være fra et sett maskiner på nettverket vårt | |
12.3.7 | ? | List of company-approved products? | |
12.3.8 | Y | bash-skall på okkupasjon er satt til å time ut etter 15 minutter (TMOUT) | |
12.3.9 | NA | Vi gir aldri tilgang til tredjepart | |
12.4 | Y | Billig sikkerhetspolicy | |
12.5a | ? | Is responsibility for information security formally assigned to a Chief Security Officer or other security-knowledgeable member of management? | |
12.5.1 | ? | Are the following information security management responsibilities formally assigned to an individual or team: Establishing, documenting, and distributing security policies and procedures? | |
12.5.2 | ? | Monitoring and analyzing security alerts and information, and distributing to appropriate personnel? | |
12.5.3 | Y | ITK har ansvaret for insidenthåndtering, inkludert eskalering og rapportering. ITKs gjengsjef har det øverste ansvaret. Se Krisehåndtering | |
12.5.4 | Y | Serveransvarlig og Billig-ansvarlig deler denne oppgaven. | |
12.5.5 | ? | Monitoring and controlling all access to data? | |
12.6a | Y | Det kreves kurs i Billig-sikkerhet for tilgang til CDE. Se også Billig sikkerhetspolicy. | |
12.6.1a | ? | Does the security awareness program provide multiple methods of communicating awareness and educating personnel (for example, posters, letters, memos, web based training, meetings, and promotions)? | |
12.6.1b | ? | Are personnel educated upon hire and at least annually? | |
12.6.1c | ? | Have employees completed awareness training and are they aware of the importance of cardholder data security? | |
12.6.2 | ? | Are personnel required to acknowledge at least annually that they have read and understood the security policy and procedures? | |
12.7 | ? | Are potential personnel (see definition of "personnel" above) screened prior to hire to minimize the risk of attacks from internal sources? | |
12.8.1 | Y | Vi holder alltid oversikt over hvilke underleverandører vi bruker i Billig sikkerhetspolicy. | |
12.8.2 | Y | Administrasjonen holder de underskrevne utgavene av avtalen som omhandler dette. | |
12.8.3 | Y | Ja, prosessen er at all kommunikasjon med underleverandørene skal skje via saksbehandlingssystemet, og til etablerte kontaktpunkter | |
12.8.4 | Y | Dette sjekker vi årlig, se Billig sikkerhetspolicy | |
12.8.5 | Y | Denne listen. | |
12.10.1a | Y | Se Krisehåndtering. | |
12.10.1(b-1) | Y | Serveransvarlig har hovedansvar. Billigansvarlig kontaktes om det er relevant Krisehåndtering | |
12.10.1(b-2) | Y | Respons er definert i Krisehåndtering | |
12.10.1(b-3) | Y | Vi har pushover, og får systemet i gang fortest mulig | |
12.10.1(b-4) | Y | Gjenopretting fra backup står i Krisehåndtering | |
12.10.1(b-5) | Y | Informere Payex og Swedbank står i Krisehåndtering | |
12.10.1(b-6) | Y | Vi får opp igjen alle kritiske systemer | |
12.10.1(b-7) | Y | se 12.10.1(b-5) | |
12.10.2 | Y | Krisehåndtering leses årlig. | |
12.10.3 | Y | Alle aktive har Pushover, som overstyrer ikke forstyrr o.l. ved kritiske varsler. | |
12.10.4 | Y | Serveransvarlig får opplæring i krisehåndtering. | |
12.10.5 | ? | Are alerts from security monitoring systems, including intrusion-detection, intrusion-prevention, and file-integrity monitoring systems, included in the incident response plan? | |
12.10.6 | Y | Krisehåndtering inkluderer punkt om postmortem. | |
A2.1 | NA | Ingen POS-Terminaler eller SSL/Early TLS | |
A2.2 | NA | Se A2.1 |
Lenker: Start, billig stripe
Epost: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2021-01-13 20:16 | Revisjon: 27 (historie, blame) | Totalt: 1904 kB | Rediger