Richtlinie - A1 Sicherheitsanforderungen an Produkte, Systeme, Applikationen

Transkript

1 Richtlinie - A1 Sicherheitsanforderungen an Produkte, Systeme, Applikationen Diese Richtlinie beschreibt die Mindest-Sicherheitsanforderungen der A1 Telekom Austria ( A1 ) an Produkte, Systeme oder Applikationen, die bei oder für A1 eingesetzt werden. Die Richtlinie gilt sowohl für A1 als auch für Lieferanten (auch Auftragnehmer genannt). Der Lieferant und/oder A1 haben die Umsetzung der Sicherheitsanforderungen im Zuge der Implementierung/Lieferung von Produkten, Systemen oder Applikationen mittels Checkliste (Security_Requirements_Checklist_2013) zu dokumentieren. Darüber hinaus gilt die A1 Information Security Policy *. A1 trifft geeignete Schutzvorkehrungen gegen folgende Bedrohungen: unerlaubtes Eindringen in das Firmennetz und damit die Gefahr der Sabotage, der Datenmanipulation und des Datendiebstahls einschleusen von malicious (bösartigem) Code ins Firmennetz blockieren von Applikationen/Services (insbesondere durch Denial of Service Attacken) alle weiteren nicht genannten zurzeit bekannten und auch zukünftigen Bedrohungen, die bei A1 Schaden verursachen könnten. Folgende Themenbereiche und Maßnahmen werden in dieser Richtlinie adressiert: 1. Security Maßnahmen (für alle Systeme erforderlich) 2. Unternehmenskritische Daten, Verkehrsdaten, Besondere Anforderungen zur Geheimhaltung von Daten (für Systeme gültig, wo diese Daten gespeichert werden) 3. Betriebliche Prozesse (für alle Systeme erforderlich) 4. Internes Kontrollsystem (für ICS-relevante Systeme) 5. Outsourcing (für ausgelagerte Systeme) OP Information Security/Legal Mai 2013_V1 1 von 7

2 1. Security Maßnahmen: 1.1. Authentifizierung Daten und sonstige in Systemen/Applikationen enthaltene Inhalte dürfen generell erst nach erfolgreicher Authentifizierung der Benutzer bzw. Zielsysteme ausgegeben werden. Die Authentifizierung eines Benutzers erfolgt mittels Kerberos mit dem Active Directory ( AD ). Das AD ist die Zentrale Benutzerdatenbank im Unternehmen der A1. Durch die Kerberos Authentifizierung wird auch SSO (Single-Sign-On) ermöglicht. Sollte Kerberos/SSO nicht möglich sein, muss eine alternative sichere Authentifizierung mit dem AD durchgeführt werden. Passwörter werden verschlüsselt im Filesystem bzw. in der Datenbank gespeichert und verschlüsselt im Netz übertragen, um das Risiko des Passwort-Diebstahls zu verringern. Hierzu werden nur State-of-the-Art Verfahren verwendet. Passwortspeicherung und Übertragung im Klartext ist verboten. Erfolgt der Zugang von außerhalb des Unternehmensnetzwerkes, muss die Authentifizierung mittels 2 Faktor Authentifizierung mit Corporate Account /PW + z.b. Zertifikat/SMS-Token/RSA- Token oder adäquater Technologie erfolgen. Zur Authentifizierung von Benutzern können auch alternative Systeme verwendet werden, die folgende Mindestkriterien erfüllen müssen: o Kennwörter mindestens 8-stellig o Komplex (Kombination aus Gross-/Kleinbuchstaben, Ziffern und Sonderzeichen) o regelmäßige Aufforderung zur Änderung des Kennworts nach z.b. 30 Tagen o Account wird automatisch nach mehrmaliger (z.b. 5) Falscheingaben gesperrt o Usernamen/Passwörter dürfen nicht fix in die Applikation programmiert sein o zufallsbasierend generierte Usernamen, woraus kein Rückschluss auf den Namen des Benutzers gezogen werden kann. Jeder angelegte User muss auch einen Account im Corporate Directory (CD) haben o rollenbasierende Berechtigungen o automatische Sperre nach Inaktivität o zwingende Änderung des Initialpasswortes nach Ersteinstieg o Passwort und Username sowie Teile davon dürfen nicht gleich sein o Die Änderung der System-, Applikations- und Datenbankkennwörter muss nach Übergabe an A1 erfolgen und hat jederzeit leicht änderbar zu sein Autorisierung Berechtigungen müssen generell rollenbasiert vergeben werden. Zentrale Autorisierung über den Standard-Genehmigungsprozess der Benutzerverwaltung. Zentrale Auflistung/Einsicht und automatische Auswertung aller Berechtigungen mit der Zugehörigkeit zu den Benutzern und Status des Accounts, z.b. gesperrt, deaktiviert, etc Hardening Nicht benötigte Ports, Schnittstellen und Services sind deaktiviert. Eine Beschreibung der benötigten Ports ist dokumentiert. Systeme werden frei von bekannten Sicherheitsmängeln an den A1 Betrieb übergeben. Default Passwörter werden vor der Übergabe an den A1 Betrieb geändert. OP Information Security/Legal Mai 2013_V1 2 von 7

3 Die Verwendung des Standard Virenschutzes, den es bei A1 für die entsprechende Plattform bereits gibt, muss möglich sein. Der Auftragnehmer hat die dafür notwendigen Informationen bei A1 einzuholen. Die Hardening Maßnahmen und der Patchstand werden durch Vulnerability Scans von A1 regelmäßig überprüft. Der Hersteller/Lieferant stellt Security-Patches spätestens 1 Woche nach öffentlicher Bekanntgabe auf Security Plattformen (CERT, SecurityTracker, Heise, etc.) oder in einem Zeitraum der im Service Level Agreement (SLA) definiert ist, bereit. Der Hersteller/Lieferant stellt Security-Patches spätestens 2 Wochen nach Entdecken mit den A1 Vulnerability Management-/Scan-Tools oder in einem Zeitraum der im SLA definiert ist, bereit. Es muss die automatisierte Möglichkeit geben, heruntergeladene Patches bzw. Software Updates auf ihre Integrität zu überprüfen Protokollierung Zentrale Protokollierung: o Login (erfolgreich/nicht erfolgreich) und Logoff o Protokollierung von Änderungen an Benutzerkonten und Berechtigungen o Protokollierung des Zurücksetzens von Passwörtern o Protokollierung der Änderungen an der Konfiguration von Komponenten o Protokollierungsdaten sind entsprechend den gesetzlichen und internen Vorgaben aufzubewahren Protokolldaten müssen mindestens folgende Daten enthalten: o Datum und Uhrzeit, Hostname/IP-Adresse, Account, Applikation/Service Export der Protokolldaten in einem allgemein bearbeitbaren Format (z.b. CSV, XML, syslog) muss möglich sein Architektur Applikationen sind in mehreren Tiers aufzubauen die sicher voneinander zu trennen sind, beim Zugriff darf kein Tier übersprungen werden. Der Zugriff von einem Tier zum nächsten ist nur über definierte Protokolle (Ports) möglich. Es muss eine Trennung in Test-, Integrations- und Produktivsystem erfolgen. Entwickler haben ohne ausdrückliche schriftliche Erlaubnis seitens A1 - auf dem Produktivsystem keinen Zugriff Der Einsatz von SNMP (Simple Network Management Protocol) wird aus sicherheitstechnischen Gründen nicht unterstützt Softwareentwicklung Die Entwicklung der Software erfolgt nach den Regeln der Informationssicherheit unter Berücksichtigung des OWASP Development Guide bzw. ÖNORM A7700 in der aktuellen Version. Berücksichtigung der OWASP Top 10 Application Security Risks. In der Test- und Change-Management Phase wird das Endergebnis von A1 mit einem Tool auf Sicherheitsmängel untersucht (z.b. Penetration Tests). Die Mängel sind vom Lieferanten ohne zusätzliche Kosten zu beheben Verschlüsselung Das System bietet die Möglichkeit, Daten bei Bedarf gezielt zu verschlüsseln (sowohl während der Übertragung, als auch beim Speichern auf Datenträger). OP Information Security/Legal Mai 2013_V1 3 von 7

4 Bereits in der Design- bzw. Ausschreibungsphase des Systems wird seitens A1 festgelegt, welche Daten verschlüsselt werden müssen; fehlen solche Anforderungen wird der Lieferant die notwendigen Informationen proaktiv bei A1 einholen Administration Eine direkte Verbindung auf ein System zum Zwecke der Administration ist nur innerhalb des A1 Netzwerkes erlaubt. Soll die Administration von außerhalb (des A1 Netzwerkes) erfolgen, darf nur eine Verbindung über festgelegte Ports der Firewall zu einem Zugangspunkt in der Demilitarized Zone (DMZ) möglich sein, von dem aus man sich dann auf das jeweilige Ziel-System weiter verbinden kann. Zur Administration sind sichere Applikationen (z.b. ssh, sftp, etc.) einzusetzen, welche über sichere Datenprotokolle (z.b. SSL) mit den Systemen kommunizieren. 2. Unternehmenskritische Daten, Verkehrsdaten, Besondere Anforderungen zur Geheimhaltung von Daten 2.1. Unternehmenskritische Daten Folgende Maßnahmen sind zusätzlich zu treffen, wenn bei Produkten bzw. Systemen oder Applikationen Kunden-, Verkehrs- oder andere schützenswerte Daten (siehe RL Unternehmenskritische Daten *) verarbeitet bzw. gespeichert werden oder Schnittstellen zu diesen Daten bestehen: Logging Protokollierung des Zugriffs/Exports unternehmenskritischer Daten Protokollierungsdaten sind entsprechend den jeweils aktuellen Vorgaben der A1 aufzubewahren, jedenfalls muss eine entsprechende Parametrisierung des Loggins möglich sein Löschen von Daten Kunden-, Verkehrs- oder andere schützenswerte Daten sind nach gesetzlichen Vorgaben der A1 zeitgerecht, regelmäßig, automatisiert zu löschen. Dies ist in der Designphase von A1 zu spezifizieren; fehlen solche Spezifikationen wird der Lieferant die notwendigen Informationen proaktiv bei A1 einholen. Jedenfalls hat der Lieferant die Daten zu löschen, wenn diese nicht mehr zur Erfüllung der vertraglichen Pflichten benötigt werden Verschlüsselung Kunden-, Verkehrs- oder andere schützenswerte Daten sind sowohl während der Übertragung im Datennetz, als auch beim Speichern auf Datenträgern zu verschlüsseln Penetration Test OP Information Security/Legal Mai 2013_V1 4 von 7

5 um den Sicherheitslevel zu evaluieren, werden Methoden des Penetration Testing verwendet. Mit Black- oder Whitebox Tests werden Angriffe simuliert. Der Lieferant muss gefundene Sicherheitsmängel umgehend beheben Vulnerability Scans Die Produkte bzw. Systeme oder Applikationen müssen in einem gehärteten und aktuell gepatchten Zustand geliefert bzw. implementiert werden. Vor Inbetriebnahme wird dies mittels Vulnerability Scans, die von A1 durchgeführt werden sichergestellt (dies als Teil des Abnahmeprozesses). Für Sicherheits-Schwachstellen, die nach Inbetriebnahme entdeckt werden, muss der Lieferant notwendige Updates kostenfrei zur Verfügung stellen Verkehrsdaten Wenn ein System Verkehrsdaten verarbeitet, sind alle Anforderungen der Richtlinie Vorratsdatenspeicherung und Datenlöschung* sowie die Anforderungen der jeweils aktuellen Richtlinien der A1 zum Thema Verkehrsdaten* einzuhalten Besondere Anforderungen zur Geheimhaltung von Daten Wenn ein System Daten unterschiedlicher Geschäftsbereiche in der A1 verarbeitet, muss eine Trennung der Geschäftsbereiche mittels definierter Zugriffsrechte möglich sein. 3. Betriebliche Prozesse 3.1. Anforderungsmanagement Die strukturierte Abhandlung von technischen Demands (Anforderungen) für eine neue Geschäftsanforderung oder eine Änderung einer bestehenden technischen Lösung sind über den von A1 vorgegebenen Prozess abzuwickeln Changemangement Alle Änderungen auf einem System od. Applikation müssen gemäß dem von A1 vorgegebenen Changeprozess durchgeführt werden Tests Änderungen auf einem System od. Applikation müssen entsprechend den Vorgaben des A1 Demand bzw. Changeprozesses vor Inbetriebnahme getestet werden Verwaltung von Daten und Jobverwaltung Die Abläufe für Backup, Restore und Jobabläufe müssen in die vorhandenen Prozesse von A1 eingebunden werden. OP Information Security/Legal Mai 2013_V1 5 von 7

6 4. Internes Kontrollsystem 4.1. Implementierung von Kontrollen Wenn ein neues System installiert wird, muss eine Relevanzanalyse mit dem ICS Competence Center durchgeführt werden. Wenn eine ICS-Relevanz besteht, müssen alle Kontrollen des internen Kontrollsystems auf dem System durchgeführt werden. Die Ansprechpartner für die Implementierung der Kontrollen sind die Process- und Control Responsibles in A1. Die Minimalanforderung sind die IT General Controls von A1 (siehe A1 ITGC _Kontrollliste*) Laufende Durchführung von Kontrollen Der Bereich Operation Information Security in A1 koordiniert die Implementierung und regelmäßige Durchführung der Kontrollen. 5. Outsourcing Wenn ein System oder Systemteile an entsprechende Lieferanten ausgelagert werden, gilt Folgendes: 5.1. Betrifft alle Systeme/Systemteile Der Lieferant hat ein Sicherheitskonzept über die Sicherheit der Daten vorzulegen, welches von A1 im Rahmen der Angebotsverhandlungen bewertet wird. Alle unter Punkt 1 Security Maßnahmen, Punkt 2 Unternehmenskritische Daten, Verkehrsdaten und Besondere Anforderungen zur Geheimhaltung von Daten sowie Punkt 3 Betriebliche Prozesse angeführten Maßnahmen müssen vom Auftragnehmer erfüllt werden. Service Level Agreements (SLAs) müssen vertraglich vereinbart werden und haben gemäß den jeweiligen Anforderungen von A1 z.b. entsprechende Pönalen bei Nichteinhaltung vorzusehen. Eine Zuständigkeitsmatrix der jeweiligen Leistungen muss vertraglich vereinbart werden Sicherheitsvorfälle (zb Einbruch, Sicherheitslücken, etc) beim Auftragnehmer im Rahmen der Vertragserfüllung müssen unverzüglich an A1 gemeldet werden Zusätzliche Anforderungen, wenn das System ICS-relevant ist: Der Auftragnehmer ist zertifiziert Der Anbieter muss ein Zertifikat für die zu erbringenden Tätigkeiten aufweisen können (SSAE 16, ISAE 3402, oder ISO 27001) Es ist mindestens ein Report pro Jahr über den aktuellen Zustand des Kontrollsystems an A1 zu übermitteln Zuständigkeitsmatrix über die Abdeckung der Risiken zwischen Auftragnehmer und A1 muss vorhanden sein. OP Information Security/Legal Mai 2013_V1 6 von 7

7 Der Auftragnehmer ist nicht zertifiziert Der Auftragnehmer muss Nachweise erbringen, dass sämtliche IT-Risiken durch interne Kontrollen abgesichert sind. o Zuständigkeitsmatrix über die Abdeckung der Risiken zwischen Auftragnehmer und A1 muss vorhanden sein o Kontrollnachweise der ausgelagerten Systembereiche müssen regelmäßig vorgelegt werden o Über die betroffenen Bereiche muss A1 ein Auditrecht eingeräumt werden. 6. Auditrecht Der Lieferant ermöglicht A1, die Überprüfung der Einhaltung der A1 Sicherheitsanforderungen durchzuführen bzw. stellt die notwendigen Nachweise ohne zeitliche Verzögerung zur Verfügung. A1 wird die Ausübung des Auditrechtes mindestens 5 Werktage vorab ankündigen. Der Lieferant stellt nachweislich sicher, dass dieses Auditrecht allfälligen Subunternehmern entsprechend vertraglich überbunden wird. OP Information Security/Legal Mai 2013_V1 7 von 7