Software development is not a new profession, people had programmed systems – analog and digital – for a time much longer you will expect. I think the earliest program I know is a time measurement program, developed by some ancient greek and realized in an analog way by letting water drip out of reservoir with an individual diameter as input and having a meter as a display. But let us focus on the electronical side where we have started with electronic tubes, going to transistor based host systems and further via workstations and PCs to client server based systems and finally the cloud as a service provider. This is huge development, but what cuses it? From my perspective it is not only the availability of technology – you could still use a dumb VT100 Terminal to book a holiday home on a host computer named airbnb. And it is not only the availability of a solution – you could also connect a terminal via phone line to the airobnb server much cheaper than using your iPhone 12 with you expensive flatrate. I do believe that the driving force for changing operational models of software is the efficiency of their development.
In the beginning there was the host. He was hard to program because he could do only one thing at a time. He had only one user. And every change in a program – even a tiny change in a subroutine needs a shutdown of the whole software and sometimes the whole computer. Not very efficient.
Then computers become smaller and more easily available – maybe you remember the MicroVax or the SGI Indigo. But more people got access to this compute power, so the demand grew. Because of this the use of computers rose, but software development became less efficient. For each change in a software you need to distribute the software to millions of computers and force the users to reinstall the software. That is when patch days were invented. And people hated it. In retrospective view it was a stepback from the host computer. This is why it is mostly gone
In the same time the network was invented. The first use was the transfer of information – mail and ftp. And telnet brought back the host and the efficiency of host based software development. And client-server based computing tried to make host computing more efficient. This was done by creating fat clients, which took all the standard functions of a software which is changed seldom to the workstation and leaving the core functions, which are continuously developed, on a host-like server. This eases development a lot because changes could be implemented much faster.
In the meantime the network developed and many people started to operate their own hosts – accessing them with the actual version of a dumb terminal, the webbrowser. And people found out that they can benefit from other people work by linking alien services in their own solutions. If I access my favorite news aggregator I use the ID of my favorite search engine as a login so the developer of my news aggregator does not need to take care of developing and operation the ID management which makes his development much more effective. I call this cloud usage and it differs significant from just using somebody else’s datacenter.
This is the reason why I think that the move to the cloud is indispensable. Not because people want it, but because the development of solutions is more effective, therefore faster and therefore brings more value earlier to the user. Ignoring this leaves you behind the digitization front. And therefore the transformation into the cloud is indispensable.
Seit langem bin ich mit meiner Frau im Trekking unterwegs. Die GTA, der Alta Via Uno, der Nortkalottruta und Kungsleden, der AT, PCT und der John-Muir-Trail sind meine Freunde geworden. Und über die Jahre habe ich eine Prioritätenliste entwickelt, die nicht nur mein direktes Handeln unterwegs, sondern auch meine Ausrüstung und meine Streckenwahl bestimmt: Gesund – Trocken – Warm – Satt. In dieser Reihenfolge verteile ich meine Ressourcen.
In Trekkingausrüstung gedacht bedeutet das: Notfallpäckchen (Allzeit-Bereit-Päckchen :b), Regenjacke/Biwacksack, Daunenjacke/Schlafsack und die BP-5 Kekse. Oder in (Notfall)-Aktionen: Erste-Hilfe, Schutz suchen, warm halten und Kekse essen. Und dann in Ruhe weiterplanen oder nach Hilfe suchen.
Haben wir das schon mal durchgespielt? Leider ja. Ein gesundheitliches Problem auf dem John-Muir-Trail zwang uns zur Unterbrechung. Also 1) Gesundheitsversorgung – soweit möglich, 2) einen Platz für das Biwak suchen, 3) Zelt aufbauen, einrichten und im Schlafsack entspannen. Dann 4) den Kocher anwerfen und Essen vorbereiten. Pause. Am nächsten Tag sind wir dann ruhig weitergegangen.
Kann man dieses Modell auf die IT-Sicherheit übertragen? Ich denke ja.
Gesund. Das System funktioniert. Eine IT-Sicherheit die veraltet ist, nur einen Teil der Systemumgebung abdeckt, nicht integriert ist oder Lücken hat ist nicht zielführend. Es gilt also, die vorhandenen Sicherheitsmassnahmen funktionsfähig und effizient zu halten.
Trocken. Keine Beeinträchtigung durch externe Einflüsse. Der Perimeter- und Endpunktschutz verhindert Standard-Angriffe von aussen, sichert den Betriebsstatus. Eine Zero-Trust Architektur unterstützt das und gewährleistet die Handlungsfähigkeit
Warm. Wärme gewährleistet Handlungsfähigkeit und schafft Übersicht. Gibt die Ruhe um die Fakten zu analysieren und die Situation zu überdenken. Die Visibilität über den Zustand der Systeme – Network, Workload, Workplace Visibility – ist das sicherheitstechnische Äquivalent. Hier greift zum ersten mal die Künstliche Intelligenz ein, analysiert und bewertet was ein Mensch übersehen kann.
Satt. Energie von aussen. Baut auf und erweitert die Aktionsmöglichkeiten. Das Äquivalent der IT-Sicherheit ist Information oder spezieller: Bedrohungsinformation. Denn ich kann nur bekämpfen was ich kenne und sehe. Hier greift zum zweiten mal die Künstliche Intelligenz, macht aus unbekanntem bekanntes und damit etwas, was bewältigt werden kann.
Cisco Security Lösungen arbeiten in allen Bereichen. SecureX sichert die Gesundheit, ist ein Bindeglied, das den Zugang zu allen Lösungskomponenten gewährleistet. Secure Firewall und Secure Endpoint halten trocken, sichern das IT-System vor bekannten Angriffen. Secure Network Analytics und Secure Workload halten warm, schaffen Sichtbarkeit und Handlungsfähigkeit. Und die Talos Threat Intelligence sättigt, liefert den kritischen Informationsvorsprung um komplexe Lagen zu bewältigen.
So, we are done. Finished the work to enable the employees to work from home. Implemented a video conferencing solution. Enabled access to the company data for the home workers. And the CEO is happy too. He can now work from the tablet of his oldest daughter. Time to grab a beer and relax.
And after that well deserved beer it’s time to clean up. Have a look into the security rules and check that we are still up to date. Lets‘ see my checklist.
1. Check the remote access
Well, we opened out network to the outer world. Gave VPN access to all of our employees. Broaden the attack surface. Maybe the good old LDAP directory is not that secure anymore. Could be the right moment to enhance our login with a multi factor authentication? And may be assess the security status of all these remote-now devices?
2. Secure the new endpoints
Oops, all that devices out now. We told our people to take their company devices home. But hey – there was that guy ho said the video of his laptop was broken. We gave him VPN for his private computer. And the tablet of the CEOs‘ daughter. He said it is well managed because his daughters‘ friend knows IT and had made a million in Bitcoin. Maybe we should try to secure all that devices with an overall solution?
3. Create visibility in the network
Yeah, all that runs now for more than 3 weeks. What if somebody has already entered our network? There is enough stuff where he can hide. We should start to create some visibility. Maybe we can find these guys by looking for anomalies?
4. Reorganise Security Zones
And yes, we put all of our data on that network drive to make access as simple as possible. Hotline calls could have killed us. But right, now our financial data is visible to the engineering team. I think we should rethink what is visible to whom before these weird guys find out where to look.
5. Verify your cloud solutions
Ok, for god’s sake we started to use this cloud based messaging platform. I would not had slept for a week if we had to built that up on prem. But wait, yesterday I saw that the Executive Team shared their year end results? Hmm, it could make sense to have a closer look on how we protect our cloud services.
Most mechanical engineers are familiar with the three competing targets „time to market“, „costs“ and „quality“. And most of them also understand the costs of changes: the earlier a change happens in the product development cycle, the cheaper it gets.
An equivalent of these tripod for governmental organizations could be: time to completion, co-signing, collaboration & delegation and comprehensibility. And in security? The most obvious three axis are: Quality of detection, time to remediation and security efficiency.
Quality of detection is the first target. It covers the most urgent question: Do I really detect all attacks I need to detect without over flooding my crew with false positives? And this question leads to additional ones. Can I really detect all important attacks by supervising only the endpoint? How do I correlate information from the endpoint, the network and the datacenter? And how reliable and fast is my threat intelligence information for these three sensors?
Time to remediation is the second target. Once an incident is identified, how easy is it to drill down to patient zero, the first infection? How much time do you need to identify all other devices also attacked and penetrated? And how much time do you need to secure the rest of your system from those already infected.? Not to mention cleaning and resetting all compromised devices. And there is a similarity to engineering change here – the faster you fight an attack, the less impact this attack has on you overall system.
Security efficiency is the third target. How much resources do you need to implement a reliable holistic prevention system and to create the capacity to quickly react and defend an attack. And how much impact does your security solution have on your operational processes? Security measures which reduce the efficiency of your business processes may be cheap in security but will cost you a fortune in OPEX.
Measuring these three targets – or indicators, identifying KPIs is a difficult task, as one major component in analysis is unknown – the total number of attacks run on a specific system. So the number of attacks found by a specific security system could either be zero as the security system does not work or it could be zero as the target system does not undergo any attack. Therefore you need to define KPIs which work independently from the implementation or you need KPI which compare a before and after status.
An example for an implementation independent KPI is the ratio of false positive detections to the total number of incidents found. This is a clear KPI measuring the quality of a detection algorithm. On the opposite, the “number of incidents found“ needs to be compared in a „before and after“ manner, assuming that the total number of attacks run is constant over time.
Consequently, running intensive Proof of Concepts before selecting a new security solution is key to validate the efficiency of a solution over all three axes. I also believe that a holistic security architecture combined with an integrated portfolio of security components is best for delivering highest prevention and attack detection as well as fastest threat remediation while delivering the best operational efficiency.
An integrated solution detects attacks not only on a single point, but across the whole security architecture. Exchanging information between the security components and between the security, network and IT infrastructure increases the ease of investigation. And integrating IT and security operations improves the operational efficiency.
Informationstechnologie, die ein Nutzer sich selbst beschafft und ohne Wissen der IT-Verantwortlichen im Kontext seiner beruflichen IT-Infrastruktur nutzt, wird umgangssprachlich gerne als Schatten-IT bezeichnet. Die Bandbreite dieser Schatten-IT reicht vom privaten Email-Account, der genutzt wird, um vertrauliche Daten zur wochenendlichen Bearbeitung auf den heimischen Rechner zu transferieren, über das Tablet mit dem sich die Sitzungsmitschriften doch einfacher erstellen lassen und die dann über das private Cloud-Konto wieder auf den Organisationsrechner wandern, bis hin zum privaten online Chat- und Collaborationaccount mit dem das berufliche Zusammenwirken und der Informationsaustausch über das private Smartphone organisiert werden. Gemeinsam ist diesen Lösungen, dass es sich bei Ihnen fast immer um Cloud-Lösungen handelt, die das gemeinsame Agieren von Nutzern über öffentlich zugängliche Internet-Server realisieren. Diese Schatten-IT wird im Allgemeinen bereits als gefährlich angesehen, denn durch Ihre Nutzung entstehen Abhängigkeiten von unkontrolliert aufgesetzten IT-Lösungen und deren Protagonisten, es werden bestehende Sicherheitsmechanismen außer Kraft gesetzt und es besteht das erhöhte Risiko des unautorisierten Datenabflusses. Besondere Gefahren entstehen, wenn Schatten-IT sich im Umfeld besonders schützenswerter Informationen etabliert hat, denn in diesen hat der Abfluss schützenswerter Informationen besonders schwere Auswirkungen. Des Weiteren ist diese Schatten-IT auch zugleich das bevorzugte Ziel des vom State-Actor betriebenen Hackings und ist damit besonderen Belastungen ausgesetzt.
Trotzdem ist es durchaus bekannt, dass sich gerade im Umfeld der Collaboration und Communication eine Kommunikationskultur etabliert hat, in der sich die spontane Gruppenbildung und der Austausch von Lageinformationen – bis hin zum abfotografierten Bildschirm – als organisationsübergreifende Führungsmittel etabliert haben. Dabei agieren die Protagonisten jedoch nicht im Umfeld fehlender Richtlinien oder fehlender Aufklärung vielmehr ist es eine persönliche Abwägung des operativen Vorteils gegen den Regelverstoß, die den Nutzer dazu bringen, bewusst die Richtlinien der Organisation zu verletzen.
Das Kernproblem ist somit nicht der Regelverstoß des Nutzers, sondern die mangelnde Akzeptanz einer bestehenden oder das Fehlen einer von Nutzer als (Überlebens)notwendig eingeschätzten Lösung. Der Nutzer weist somit die IT-Organisation mit der Nutzung der Schatten-IT also auf eine Fähigkeitslücke in der Gestaltung des IT-Lösungsportfolios hin und stellt somit einen deutlichen Handlungsindikator zum Start eines Digitalisierungsprojektes dar.
Zur Deckung der Fähigkeitslücke im IT-Portfolio ist es also notwendig dem Anwender Lösungen zur Verfügung zu stellen, die diesen DIgitalisierungsbedarf erfüllen und die die Sicherheits- und Architekturanforderungen der Organisation zumindest teilweise erfüllen. Eine Nichterfüllung des Digitalisierungsbedarfes ist keine Option, denn dies würde den Nutzer weiter in die Schatten-IT treiben und weitere, größere Sicherheitsrisiken entstehen lassen. Somit steht die IT-Organisation vor der Herausforderung Lösungen auszuwählen und zu implementieren, die aus Sicht der eigenen Organisation unzureichende Systemeigenschaften besitzen. Um diese Herausforderung zu bewältigen, bieten sich die folgenden Handlungsstrategien an.
Grundsätzliche werden Schatten-IT Lösungen im seltensten Fall auf der privaten IT-Infrastruktur eines Nutzers betrieben, sondern nutzen kommerzielle Dienste. Somit können die Ersatzlösungen in der Regel als Cloudlösung implementiert werden. Dazu können drei Varianten unterschieden werden: die Implementierung in einer abgeschlossenen Umgebung der Organisation – einer „On Premise Cloud“, die Implementierung in einer abgeschlossenen Mandanten-Umgebung eines kommerziellen Cloudanbieters, einer „Private Cloud“ oder es wird die Implementierung eines ausgewählten Anbieters genutzt, eine „Public Cloud“. Die Ablösung einer Schatten-IT erfordert also in jedem Fall die Implementierung einer Multi-Cloud- oder Hybrid-Cloud-Strategie. In der Folge erfordert dies ebenfalls die Implementierung einer Cloud-Security-Strategie um zumindest die wesentlichen Sicherheitsrisiken einer Cloud-Nutzung zu mitigieren.
Als wesentliche exemplarische Risiken in der Betrachtung einer Cloud-Security Strategie sind folgende Risiken zu nennen:
Der Informationsabfluss an den Cloudprovider
Der Informationsabfluss an andere Cloudnutzer
Informationsverlust auf der Übertragungsstrecke
Die Penetration der eigenen IT über die Cloudlösung
Die Manipulation von Informationen in der Cloud
Der ungewünschte Ausfall der Cloudlösung
Werden diese Risiken im Kontext der verschiedenen Nutzungsszenarien „On Premise Cloud“, „Private Cloud“ und „Public Cloud“ betrachtet und hinsichtlich der bekannten exemplarischen Sicherheitstechnologien zur Mitigation der Risiken analysiert ergibt sich die folgende Handlungsmatrix. Diese kann als Vorlage für eine individuell zu gestaltende Cloud-Security-Architektur dienen und sowohl in den betrachtenden Risiken, als auch in der Auswahl der umzusetzenden Maßnahmen erweitert und angepasst werden.
On Premise Cloud
Private Cloud
Public Cloud
Informationsabfluss an Cloudprovider
n/a
CiR, SLA
SLA
Informationsabfluss an Cloudnutzer
MFA
MFA, CMON
MFA, SLA
Informationsverlust auf der Übertragungsstrecke
VPN, E2E
E2E, VPN, DLP
E2E, DLP
Penetration aus der Cloud
n/a
Monitoring, IPS
Monitoring, IPS, SLA
Informationsmanipulation
n/a
VPN
VPN
Verfügbarkeit
DDoS Schutz
SLA, DDoS
SLA
n/a: Risiko nicht relevant CiR: Crypto in Rest – Verschlüsselung von Spreicherdaten CMON: Cloud Monitoring – Überwachung von Cloudanwendungen DDoS Schutz: Distributed Denial of Service Schutz DLP: Data Loss Prevention IPS: Intrusion Protection Systems SLA: Service Level Agreement Verhandlung VPN: Virtual Private Networks E2E: Ende zu Ende Verschlüsselung MFA: Multi Faktor Authentifizierung Monitoring: Überwachung der lokalen Systeme auf atypisches Verhalten
Im Allgemeinen ist die Implementierung einer Lösung in der „On Premise Cloud“ ist zu bevorzugen, da die Cloudverantwortung in der Hoheit der eigenen IT-Organisation liegt und die restlichen Risiken gut mitigieren oder nicht relevant sind. Im Gegensatz hierzu sind bei der Public Cloud viele Risiken schlecht mitigierbar und müssen über vertragliche Vereinbarungen oder Zertifizierungsanforderungen die hier übergreifend unter dem Stichpunkt SLA zusammengefasst werden, geregelt werden. Die „Private Cloud“ als Zwischenlösung stellt hier eine flexiblere Umgebung dar um individuelle Sicherheitskonfigurationen in Kooperation mit einem Cloudanbieter zu realisieren.
Zusammenfassung
Grundsätzlich ist anzustreben Schatten-IT im Rahmen von Digitalisierungsprojekten durch kontrollierte Lösungen zu ersetzen, auch wenn diese den Sicherheits- und Architekturvorgaben der eigenen Organisation nur bedingt genügen. Die dadurch entstehende hybride Cloudnutzung kann und muss durch Sicherheitstechnologie im Rahmen einer Sicherheitsarchitektur abgesichert werden. In dieser kommen sowohl technologische als auch organisatorische Maßnahmen zum Tragen.
