A small space doesn't stop this gardener from planting up colorful abundance

More fantastic plant combinations from a container connoisseur in the Mountain West

Challenging conditions don’t stop this gardener from creating new dazzling container designs every year

Discover how growing native plants in pots can create resilient, eco-friendly urban gardens

This divisive color might be just what your garden is missing

A container pro helps us celebrate Halloween with his creative fall arrangements

Day 2 of our Halloween garden countdown comes from a mother and daughter that build festive fall displays in the south

A large pool patio is full of potted possibilities

This colorful collection of plants is an oasis for this gardener and a whole host of wildlife

Even as fall settles into New England, the flowers in this patio garden continue to shine

Containers fill and spill with delicious edibles and gorgeous ornamentals started from seed

A small space doesn't stop this gardener from enjoying a vast array of interesting plants

With a little planning in the fall, you can have a gorgeous spring display to enjoy next spring. ... Read More

The post Plant and Overwinter Spring Flowering Bulbs in Pots appeared first on Garden Therapy.

More art and accessories that add style and personality to a lush New England garden

Upgrades that will transform your everyday routine

Die IT-Welt verändert sich rasant, und Container und Kubernetes (K8s) erfreuen sich immer größerer Beliebtheit. Der Wechsel von virtuellen Maschinen zu Containern und später zu Container-Koordinierungsplattformen (die erste Version von Docker wurde 2013 veröffentlicht) vollzog sich innerhalb von nur sieben Jahren. Während einige Startups noch Erfahrungen damit sammeln, wie sie von diesen neuen Ressourcen profitieren können, suchen einige etablierte Unternehmen nach Möglichkeiten, ihre veralteten Systeme zu effizienteren Infrastrukturen zu migrieren.

Die schnelle Einführung von Containern und Kubernetes zeigt die disruptive Wirkung dieser Technologien. Sie haben jedoch auch zu neuen Sicherheitsproblemen geführt. Da Container und Kubernetes so beliebt sind und von vielen Unternehmen ohne angemessene Sicherheitsmaßnahmen eingesetzt werden, sind sie perfekte Ziele für Angreifer.

Ein K8s-Cluster besteht aus mehreren Maschinen, die in einem Master-Node (und seinen Kopien) verwaltet werden. Dieser Cluster kann aus tausenden Maschinen und Services bestehen und ist daher ein hervorragender Angriffsvektor. Daher ist es wichtig, strikte Sicherheitspraktiken zu implementieren.

Absicherung Ihres Clusters

Der Kubernetes-Cluster enthält zahlreiche dynamische Elemente, die angemessen geschützt werden müssen. Die Absicherung des Clusters ist jedoch keine einmalige Angelegenheit, sondern erfordert Best Practices und ein kompetentes Sicherheitsteam.

Wir erläutern verschiedene Kubernetes-Angriffsvektoren sowie Best Practices zum Schutz Ihres K8s-Clusters.

Gewährleisten, dass Kubernetes und die Nodes auf dem neuesten Stand sind

K8s ist ein Open-Source-System, das kontinuierlich aktualisiert wird. Das GitHub-Repository gehört zu den aktivsten Repositorys der Plattform. Kontinuierlich werden neue Funktionen, Verbesserungen und Sicherheits-Updates hinzugefügt.

Alle vier Monate wird eine neue Hauptversion von Kubernetes mit neuen Funktionen zur Verbesserung des Services veröffentlicht. Gleichzeitig kommen wie bei jeder Software – und ganz besonders bei häufig aktualisierten Programmen – neue Sicherheitsprobleme und Fehler hinzu.

Doch auch in älteren Versionen werden Sicherheitsverletzungen gefunden. Es ist daher wichtig zu verstehen, wie das Kubernetes-Team in diesen Fällen mit Sicherheitsupdates umgeht. Im Gegensatz zu Linux-Distributionen und anderen Plattformen verfügt Kubernetes nicht über eine LTS-Version. Stattdessen versucht Kubernetes ein Backporting von Sicherheitsproblemen für die drei zuletzt veröffentlichten Hauptversionen.

Daher ist es wichtig, dass Ihr Cluster eine der drei zuletzt veröffentlichten Hauptversionen verwendet und Sicherheitspatches zügig implementiert werden. Außerdem sollten Sie die Aktualisierung auf die neueste Hauptversion zumindest einmal innerhalb von zwölf Monaten durchführen.

Zusätzlich zu den Hauptkomponenten verwendet Kubernetes auch Nodes, auf denen die Workloads ausgeführt werden, die dem Cluster zugewiesen sind. Bei diesen Nodes kann es sich um physische oder virtuelle Maschinen handeln, auf denen ein Betriebssystem ausgeführt wird. Dabei ist jeder Node ein potenzieller Angriffsvektor, der zur Vermeidung von Sicherheitsproblemen aktualisiert werden muss. Zur Verringerung der Angriffsfläche müssen die Nodes daher so sauber wie möglich sein.

Einschränkung der Zugriffsrechte

Rollenbasierte Zugangskontrolle (Role-based Access Control, RBAC) ist einer der besten Ansätze, um zu kontrollieren, welche Benutzer wie auf den Cluster zugreifen können. Er bietet die Möglichkeit, die Zugriffsrechte für jeden einzelnen Benutzer detailliert festzulegen. Die Regeln gelten jeweils additiv, sodass jede Berechtigung explizit gewährt werden muss. Mithilfe von RBAC können Sie die Zugriffsrechte (Anzeigen, Lesen oder Schreiben) für jedes Kubernetes-Objekt – von Pods (der kleinsten K8s-Recheneinheit) bis zu Namespaces – beschränken.

RBAC kann auch per OpenID Connect-Token auf einen weiteren Verzeichnisdienst angewendet werden, sodass die Benutzer- und Gruppenverwaltung zentral erfolgen und im Unternehmen auf breiterer Ebene umgesetzt werden kann.

Die Zugriffsrechte sind nicht nur auf Kubernetes beschränkt. Wenn Benutzer zum Beispiel Zugriff auf einen Cluster-Node benötigen, um Probleme identifizieren zu können, ist es sinnvoll, temporäre Benutzer zu erstellen und nach der Behebung der Probleme wieder zu löschen.

Best Practices für Container

Docker, die am häufigsten eingesetzte Container-Technologie, besteht aus Layern: Das innerste Layer ist die einfachste Struktur und das äußere Layer ist die spezifischste. Daher beginnen alle Docker-Images mit einer Form von Distributions- oder Sprach-Support, wobei jedes neue Layer eine Funktion hinzufügt oder die vorherige Funktion modifiziert. Der Container enthält alles, was zum Hochfahren der Anwendung erforderlich ist.

Diese Layer (auch als Images bezeichnet) können öffentlich im Docker Hub oder privat in einer anderen Image-Registry verfügbar sein. Das Image kann zum Zeitpunkt der Image-Erstellung in zwei Formen ausgedrückt werden: als Name plus Bezeichnung (z. B. Node:aktuell) oder mit einer unveränderlichen SHA-ID (z. B. sha256:d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b).

Das Image, das der Bezeichnung zugeordnet ist, kann vom Repository-Inhaber jederzeit geändert werden, d. h. das Tag aktuell weist darauf hin, dass es sich um die neueste verfügbare Version handelt. Das heißt aber auch, dass sich das innere Layer bei der Erstellung eines neuen Images oder beim Ausführen eines Images mit diesem Tag plötzlich und ohne Benachrichtigung ändern kann.

Diese Vorgehensweise verursacht einige Probleme: (1) Sie verlieren die Kontrolle darüber, was in Ihrer Kubernetes-Instanz ausgeführt wird, wenn ein äußeres Layer aktualisiert wird und einen Konflikt verursacht, oder (2) das Image wird absichtlich modifiziert, um eine Sicherheitsschwachstelle hinzuzufügen.

Um das erste Problem zu umgehen, vermeiden Sie das Tag aktuell und wählen ein konkretes Tag, das die Version beschreibt (z. B. Node:14.5.0). Und um das zweite Problem zu vermeiden, wählen Sie offizielle Images und klonen Sie das Image in Ihr privates Repository oder verwenden Sie den SHA-Wert.

Ein weiterer Ansatz besteht darin, ein Tool zur Schwachstellenerkennung einzusetzen und die Images kontinuierlich zu prüfen. Diese Tools können mit kontinuierlichen Integrations-Pipelines parallel ausgeführt werden und das Image-Repository überwachen, um zuvor unerkannte Probleme zu identifizieren.

Bei der Erstellung eines neuen Images müssen Sie beachten, dass jedes Image immer nur einen Dienst enthalten sollte. Außerdem sollte die Zahl der Abhängigkeiten auf ein Minimum beschränkt werden, um die Angriffsfläche auf die Komponenten zu reduzieren, die für den Dienst unerlässlich sind. Wenn jedes Image nur eine Anwendung enthält, lässt es sich zudem leichter für neuere Versionen aktualisieren. Es wird auch einfacher, Ressourcen zuzuweisen.

Netzwerksicherheit

Im vorherigen Abschnitt ging es um die Reduzierung der Angriffsfläche. Das gilt auch für die Netzwerkfunktionen. Kubernetes enthält virtuelle Netzwerke innerhalb des Clusters, die den Zugriff zwischen Pods beschränken und externe Zugriffe erlauben können, sodass nur der Zugriff auf genehmigte Dienste möglich ist. Das ist eine primitive Lösung, die nur in kleinen Clustern funktioniert.

Größere Cluster, die mehrere, von verschiedenen Teams entwickelte Dienste enthalten, sind jedoch deutlich komplexer. In diesen Fällen ist ein zentraler Ansatz eventuell nicht umsetzbar, stattdessen gelten Service Meshes als bestmögliche Methode. Das Service Mesh erstellt eine Netzwerkverschlüsselungsebene, über die Dienste sicher miteinander kommunizieren können. Sie fungieren meist als Sidecar-Agent, d. h. sie werden wie ein Beiwagen an jeden Pod angefügt und ermöglichen die Kommunikation zwischen den Diensten. Service-Meshes übernehmen nicht nur Sicherheitsfunktionen, sondern ermöglichen zudem Erkennung, Überwachung/Nachverfolgung/Protokollierung und vermeiden Dienstunterbrechungen, indem sie zum Beispiel ein als Circuit Breaking (Sicherung) bezeichnetes Entwurfsmuster verwenden.

Festlegen von Ressourcenkontingenten

Da Anwendungen quasi permanent aktualisiert werden, genügt es nicht, für die Absicherung Ihres Clusters einfach die oben beschriebenen Methoden zu implementieren. Das Risiko einer Sicherheitsverletzung bleibt weiterhin bestehen.

Ein weiterer wichtiger Schritt ist die Verwendung von Ressourcenkontingenten, bei denen Kubernetes die Ausfallabdeckung auf die festgelegten Grenzen beschränkt. Wenn diese Grenzen gut definiert sind, wird verhindert, dass im Falle einer Ressourcenerschöpfung alle Cluster-Dienste ausfallen.

Außerdem wird verhindert, dass zum Ende des Monats massive Kosten für die Cloud-Bereitstellung anfallen.

Überwachung und Protokollierung

Die Überwachung des Clusters (vom Cluster bis zu den Pods) ist für die Erkennung von Ausfällen und Identifizierung von Ursachen unerlässlich. Dabei geht es vor allem um die Erkennung von ungewöhnlichen Verhaltensweisen. Wenn der Netzwerkverkehr zugenommen hat oder sich die CPU der Nodes anders verhält, sind weitere Untersuchungen zur Problemsuche erforderlich. Während es bei der Überwachung mehr um Kennzahlen wie CPU, Arbeitsspeicher und Netzwerkleistung geht, kann die Protokollierung zusätzliche (historische) Informationen liefern, mit denen sich ungewöhnliche Muster oder die Quelle des Problems schnell identifizieren lassen.

Die Tools Prometheus und Graphana sind in Kombination für die effektive Überwachung von Kubernetes geeignet. Prometheus ist eine hochleistungsfähige Zeitreihen-Datenbank, während Graphana die Daten aus Prometheus lesen und in übersichtlichen grafischen Dashboards darstellen kann.

ElasticSearch ist ein weiteres nützliches Tool und gehört zu den beliebtesten Tools für die zentrale Protokollierung von Anwendungen, Nodes und Kubernetes selbst fast in Echtzeit.

Cloud oder lokal – die Sicherheitsaspekte

Eine Kubernetes-Installation kann lokal oder über einen Cloud-Management-Dienst erfolgen. Bei einer lokalen Bereitstellung muss jede Konfiguration (Hochfahren neuer Maschinen, Einrichtung des Netzwerks und Absicherung der Anwendung) manuell durchgeführt werden. Bei Cloud-basierten Diensten wie Google GKE, AWS EKS oder Azure AKS kann K8s mit minimalem Konfigurationsaufwand installiert werden. Sie sind dann automatisch mit anderen Diensten dieses Dienstanbieters kompatibel.

In Bezug auf die Sicherheit benötigen lokale Lösungen erheblich mehr Aufmerksamkeit. Wie bereits erwähnt, muss jedes neue Update heruntergeladen und vom System konfiguriert werden, und die Nodes müssen ebenfalls aktualisiert werden. Es wird daher empfohlen, dass lokale Kubernetes-Umgebungen nur von einem erfahrenen Team bereitgestellt werden.

Bei Diensten, die über die Cloud verwaltet werden, ist der Prozess hingegen deutlich einfacher: Kubernetes ist bereits installiert und der Cloud-Anbieter sorgt dafür, dass alle Nodes auf dem aktuellen Stand sind und über die neuesten Sicherheitsfunktionen verfügen. In Bezug auf die Cluster bieten die meisten Cloud-Anbieter Benutzern die Option, eine von mehreren K8s-Versionen zu wählen. Außerdem stellen sie Möglichkeiten zur Aktualisierung auf eine neue Version zur Verfügung. Somit ist diese Vorgehensweise einfacher, aber weniger flexibel.

Abschließende Anmerkungen

In Anbetracht ständiger Updates und der Flut an Tools, die auf den Markt gelangen, bedeuten Aktualisierungen und das Schließen von Sicherheitslücken einen erheblichen Aufwand. Dadurch sind Breaches praktisch unvermeidbar. Bei Kubernetes ist die Herausforderung noch größer, da es sich nicht nur um ein Tool handelt. Vielmehr besteht Kubernetes aus mehreren Tools, die wiederum weitere Tools, Maschinen und Netzwerke verwalten. Die Sicherheit spielt daher eine zentrale Rolle.

Angesichts dieser dynamischen Umgebung ist die Absicherung von Kubernetes alles andere als einfach. Berücksichtigen Sie daher diese Tipps:

• Überprüfen Sie Anwendungen, die auf K8s laufen, auf Sicherheitsprobleme.
• Beschränken und kontrollieren Sie den Zugriff.
• Stellen Sie sicher, dass alle Komponenten die neuesten Sicherheitsupdates enthalten, und überwachen Sie den Cluster kontinuierlich, um Ausfälle sofort beheben und so Schaden zu vermeiden.

Die Herausforderung ist bei lokalen Bereitstellungen noch größer, da hier echte Hardware verwaltet, Automatisierungen eingerichtet und mehr Software-Programme aktualisiert werden müssen. Wenn Sie die hier beschriebenen Best Practices befolgen, profitieren Sie von einem großen Sicherheitsvorteil und können den sicheren und zuverlässigen Betrieb Ihrer Kubernetes-Umgebung gewährleisten.

Die SentinelOne-Plattform unterstützt physische und virtuelle Maschinen, Docker, selbstverwaltete Kubernetes-Instanzen und über Cloud-Dienstanbieter verwaltete Kubernetes-Implementierungen wie AWS EKS. Wenn Sie mehr erfahren möchten, fordern Sie noch heute eine kostenlose Demo an.

The post Kubernetes – Sicherheitsprobleme, Risiken und Angriffsvektoren appeared first on SentinelOne DE.

Cloud technology has afforded organizations the ability to operate dynamically and build new technologies quickly while keeping costs low. However, as organizations move away from on-premises IT infrastructure, they may lose visibility into their new cloud-based assets. 

Cloud environments, such as the big three cloud providers (Amazon, Google and Microsoft), vastly differ from provider to provider. Large organizations likely have assets in more than one cloud environment, which creates a challenge for security teams. Specialized knowledge is needed to ensure proper configuration across cloud environments, otherwise it’s easy to lose track of existing assets and their conditions.

The likelihood that a cloud container (or bucket or blob) is improperly configured, exposing assets to the public internet, is high. One checkbox missed when setting up an application in a cloud environment could expose information unknowingly. 

This is why security teams need access to offensive security testing that provides the specific expertise needed per cloud provider. 

How Synack Solves for Pentesting in the Cloud

Enter the Synack Red Team (SRT) and platform. The SRT is a community of more than 1,500 security researchers, each chosen for their skillset, resulting in a large, diverse pool to perform pentests or other security testing for the cloud. 

When setting up an SRT engagement with Synack, we’ll find the right security researchers with expertise tailored to your cloud or multi-cloud environment. We also handle dynamic IPs–often associated with cloud environments–with ease, updating the scope of a project every night so that deployed SRT researchers stay on target.

Whether you need IT infrastructure checked in your Microsoft Azure environment or important assets reviewed in Amazon S3 buckets, the Synack Platform has you covered. After SRT reports are vetted for high impact misconfigurations and exploitable vulnerabilities, the platform delivers reports with as much or as little detail as needed. You can also request a patch verification within the platform to ensure any remediations or reconfigurations really worked.

With Synack, you can see security trends over time. If you’re just beginning your digital transformation—moving from on-prem to the cloud—or your organization has spent years building cloud infrastructure and applications, you need to be able to demonstrate to leadership that your security measures are effective. 

From round-the-clock coverage to one-off cloud vuln checklists, Synack can sniff out exploitable vulnerabilities and help you, through data and proof-of-work, build a hardened cloud attack surface.

The post Untangling Your Cloud Assets with Offensive Security Testing appeared first on Synack.

Why You Need to Pentest Your Cloud Implementation and What’s Different From Normal Pentesting

Security Breaches in Cloud Systems

Most businesses today perform at least some of their compute functions in the cloud. For good reason. Processing in the cloud can lead to increased productivity while reducing capital and operational costs. But, as with any computer system, there can be holes in security that hackers can exploit. In 2021, the average cost was $4.8 million for a public cloud breach, $4.55 million for a private cloud breach, and $3.61 million for a hybrid cloud breach. 

Breaches can also lead to the exposure of customer records. In May 2021, a Cognyte breach exposed 5 billion customer records. Perhaps the most high profile breach was at Facebook. In April of that year, hundreds of millions of customer records were exposed. Cloud customers need to be mindful of cloud security and take necessary steps to protect themselves.

What is Pentesting?

Penetration testing, or pentesting, is a well-proven and critical component of any organization’s cybersecurity program. In a pentest, a trusted team of cybersecurity researchers probes your IT systems for vulnerabilities that could allow them to breach your defenses, just as a cybercriminal would do. The result of the pentest is a report on your cybersecurity posture, including vulnerabilities that need to be remediated.

Pentesting methods and practices were primarily developed with on-premises systems in mind. But today, organizations are moving more of their compute processing and data storage to the cloud. So you might ask – Is pentesting necessary for my cloud implementation?  Can you even do pentesting in the cloud? The answer to both questions is a definite yes.

Why You Need to Pentest the Cloud

Whether you are using the cloud for IaaS (Infrastructure as a Service), Paas (Platform as a Service) or SaaS (Software as a Service) cloud usage is essentially a shared responsibility model where both the Cloud Service Provider (CSP) and the tenant share certain responsibilities, including cybersecurity. There are several potential risks and vulnerabilities that are inherent in using cloud services, such as the extensive use of APIs for communication, the potential for misconfiguration of servers and the use of outdated software or software with insecure code. If not remediated these vulnerabilities could lead to a breach. The top concerns of cloud operation are data loss, data privacy, compliance violations and exposure of credentials.

Pentesting in the Cloud

The big difference in pentesting your own system and pentesting in the cloud is that you are actually testing someone else’s system. In public and hybrid cloud implementations, in addition to shared responsibility considerations, you also have shared resources considerations. You don’t own the cloud resources, so you need to create your testing process to operate within the CSP environment.

Challenges Specific to Cloud Pentesting

While offloading work to the cloud has broad benefits, it also has some drawbacks. One is the lack of transparency. You don’t know exactly what hardware is being used or where your data is stored. This can make thorough pentesting more difficult.  And since you are working with a resource sharing model, there is the potential for cross-account contamination if the CSP has not taken adequate steps to segment users. Most important from a testing perspective, each CSP has its own policy regarding pentesting on their systems.

Working With CSPs for Pentesting

Most CSPs will allow pentesting on their systems…as long as you adhere to their guidelines and restrictions. If you have a multi-cloud implementation, involving two or more CSPs, you need to ensure that you understand the pentesting policies of each. Here are a few of the considerations when pentesting in the cloud.

• CSP Notification: The first thing you need to do is inform your CSP that you will be conducting a test. Otherwise, your efforts could look like a cyberattack. 
• CSP testing restrictions: Often CSPs will have a policy describing which tests you can perform, what tools you can use, and which endpoints can and cannot be tested. 
• The Shared Responsibility Model: Depending if you have an IaaS, PaaS, or SaaS model, you are responsible for security of some cloud components and the CSP is responsible for some. 
• Server-Side Vulnerabilities: Conducting a thorough penetration test might discover vulnerabilities that are on the server side and therefore the CSP’s responsibility. 

Pentest for a More Secure Cloud

Not only can you pentest in the cloud, you need it to be part of your cybersecurity process. Remediating vulnerabilities discovered by pentesting will improve the security of your cloud implementation. It can also help you achieve compliance and give you a more comprehensive understanding of your cloud system. Synack’s approach to pentesting for the cloud addresses the concerns relayed here—you can set up a pentest for your cloud environment in minutes with some of the world’s top cloud security experts. 

The post Pentesting for Cloud Systems: What You Need to Know appeared first on Synack.