von Michael Wager | Jun 17, 2024 | Cyber-Sicherheit, News, Unkategorisiert
Von Michael Wager
As cybersecurity threats continue to evolve, the need for robust vulnerability management tools has never been greater. One such powerful open-source tool is OWASP’s DefectDojo. At secureIO, we do not only use DefectDojo to manage and track vulnerabilities, but we also actively contribute to its development. This blog post will introduce the features of the tool and also highlight our recent contributions.
What is OWASP DefectDojo?
OWASP DefectDojo is an open-source application vulnerability management tool that helps security teams track, manage, and report on vulnerabilities discovered in their environments. It simplifies the complex process of vulnerability tracking and provides valuable insights through comprehensive dashboards and reports. Key features include:
- Centralized vulnerability management: Results of scanner, manual Penetration-Tests etc will be imported centrally
- Detailed reporting and analytics: be able to quickly communicate a products security stance
- Integrations with various scanning tools: supports >170 Scanners out of the Box (like Checkmarx, Nessus, BurpSuite, etc.)
- Role-based access control
- Risk acceptance: change status of findings (e.g. false positives, accept risk etc)
- Deduplication: compares findings to automatically identify duplicates
- Service Level Agreement (SLA): allows you to maintain your security SLAs and automatically remind teams whenever a SLA is about to get breached, or is breached
Our Contributions to DefectDojo
secureIO is always trying to give back to the community, that’s why we have a public GitHub Organization where all our open-source projects are hosted. See github.com/secureIO-GmbH.
After introducing and setting up DefectDojo for a large enterprise customer, we found that it did not support a certain scanner used by their teams, so we quickly aligned with the OWASP community and created a pull request to create a new Parser: https://github.com/DefectDojo/django-DefectDojo/pull/10064. This parser enhances the tool’s ability to interpret and import findings from an additional security scanner called Kiuwan, further expanding its versatility and usability.
More Open Source Engagement at secureIO
Some months ago, we also started our own open-source project: Vulnerability-Heatmap. The idea comes from the need to visualize security vulnerabilities across multiple projects in a heatmap representation. The orchestration and tracking has become quite complex, especially for central security teams in large enterprises dealing with a multitude of distributed teams. The heatmap is built for the ease of adaptation by technology management and development roles to identify the critical outliers within the organization. The different views of the heatmap allow tailored representation of configurable criteria over time and across projects. The Vulnerability Heatmap is particularly helpful for Security Awareness and Security Champions programs by giving an easy consumable representation of the enterprise’s flaws. Best-practice guidance for incorporation in your Awareness program will be referenced in the future.
As this project is open source anyway, we had the idea of putting it into DefectDojo, but we are still in contact with its maintainers. They currently have a feature freeze because v3 will be rolled out soon.
Conclusion
At secureIO, we are committed to enhancing the tools and resources available to the cybersecurity community. Our contributions to OWASP DefectDojo reflect our dedication to improving security and helping the community.
Stay tuned for more updates as we continue to innovate and contribute to the open-source cybersecurity ecosystem.
Feel free to reach out to us if you have any questions or need help integrating these tools into your security workflow. We are always here to help you enhance your cybersecurity defenses!
von Michael Wager | Okt 19, 2023 | Cyber-Sicherheit, News
Recently we gave a talk at the
BSides Conference in Munich. Container security is an ongoing concern for organizations. Often seen as a „black box,“ containers pose challenges in addressing vulnerabilities, especially when base image updates are not readily available. Security scanners detect numerous findings, and even critical issues can be hard to resolve. In our exploration, we delve into practical approaches and best practices to minimize your container’s attack surface and also share some insights into our scientific research project collaboration with the
University of Applied Sciences, Augsburg. We guide you on the journey to strip away unnecessary components, moving towards fully distroless containers. We also examine whether the „distroless“ concept offers a solution to your security concerns, shedding light on expectations, challenges, and potential outcomes.
You can find the slides
here.
von Michael Wager | Apr 25, 2023 | GRC & Informationssicherheit, News
von Dominik Weyand
Anpassung der Normen
Seit der letzten Revision sind die Cybergefahren stark angestiegen, die Anforderungen an den Datenschutz wurden verschärft und die technische Entwicklung ist vorangeschritten. Aus diesen Gründen war es notwendig die Anforderungen an die ISO/IEC 27002 sowie an die ISO/IEC 27001 von Grund auf zu überarbeiten. Diese Anpassungen wurden in Form der ISO/IEC 27001:2022 und der ISO/IEC 27002:2022 bereits veröffentlicht.
Änderungen durch die Revision
Die wesentlichen Änderungen beziehen sich auf die inhaltliche Umstrukturierung der ISO/IEC 27002. Vergleicht man die beiden Gliederungen, so ist schnell erkennbar, dass in dem neuen Standard aus 114 Maßnahmen in 14 Bereichen 93 Maßnahmen in 4 Bereichen geworden sind. Die Reduzierung ist dadurch erklärbar, dass bestimmte Inhalte zusammengefasst, allerdings nicht weggefallen sind. Zusätzlich gibt es 11 neue Maßnahmen, welche in dieser Form im vorherigen Standard nicht existieren. Weiterhin wird in der neuen Version das Ziel jeder Maßnahme explizit definiert und durch weitere Informationen spezifiziert. Die folgenden 11 neuen Maßnahmen wurden aufgenommen, um aktuelle Entwicklungen in der Informationssicherheit zu berücksichtigen:
| 5.7 Bedrohungsintelligenz |
Organisatorische Maßnahme |
| 5.23 Informationssicherheit für die Nutzung von Cloud-Diensten |
Organisatorische Maßnahme |
| 5.30 IKT-Bereitschaft für Geschäftskontinuität |
Organisatorische Maßnahme |
| 7.4 Überwachung der physischen Sicherheit |
Physische Maßnahme |
| 8.9 Konfigurationsmanagement |
Technologische Maßnahme |
| 8.10 Löschung von Informationen |
Technologische Maßnahme |
| 8.11 Datenmaskierung |
Technologische Maßnahme |
| 8.12 Verhinderung von Datenverlusten |
Technologische Maßnahme |
| 8.16 Überwachungstätigkeiten |
Technologische Maßnahme |
| 8.23 Web-Filterung |
Technologische Maßnahme |
| 8.28 Sichere Kodierung |
Technologische Maßnahme |
Hierbei muss beachtet werden, dass nicht einfach alle Maßnahmen aus dem Anhang abgearbeitet werden sollen, sondern die Risiken aus der jeweiligen Unternehmensperspektive zu betrachten sind. Die neue Version fordert also, dass dem Blick in den Normenkontext der Blick auf die Situation und die Bedürfnisse des Unternehmens vorausgehen muss. Auf dieser Grundlage müssen die Risiken analysiert und Maßnahmen für das Unternehmen abgleitet werden.
Neben den signifikanten Änderungen des Anhangs wurden auch einige Stellen in der Norm angepasst. So wurden beispielsweise in den Kapiteln einzelne Anforderungen umformuliert oder durch zusätzliche Aufzählungspunkte ergänzt. Darüber hinaus wurde das Unterkapitel 9.3 Managementbewertung stärker untergliedert, um die Bedeutung dieser hervorzuheben. Ebenso wurde die Reihenfolge in Kapitel 10 Verbesserung getauscht, wodurch die fortlaufende Verbesserung vor den Umgang mit Nichtkonformitäten und Korrekturmaßnahmen gestellt wird.
Handlungsbedarf
Die neuen Anpassungen im Anhang sorgen dafür, dass das Informationssicherheitsmanagement gemäß ISO/IEC 27001 mit anderen Managementsystemen zu einem integrierten Managementsystem zusammengefügt werden kann und die Unternehmen somit von den Synergieeffekten profitieren. Auf Grund der stetig steigenden Anzahl an Anforderungen und Managementsystemen führt dies zu einer Reduzierung des operativen Aufwands. An erster Stelle sollen allerdings die zuvor genannten Änderungen bereits enthaltene Inhalte spezifizieren und keine grundlegend neuen Anforderungen an das Informationssicherheitssystem stellen. Während das Managementsystem also weitestgehend gleich bleibt, liegt die wirkliche Arbeit beim Umstieg auf die neue ISO 27001:2022 in der Umstellung der Risikoanalyse auf die neuen Controls. Die Übergangsfrist für die Umstellung auf die neue Version beläuft sich gemäß den Vorgaben des International Accreditation Forum (IAF) auf den 31.10.2025. Unternehmen, die vor einer Rezertifizierung stehen, können bis zu diesem Zeitpunkt entscheiden, ob sie nach dem bisherigen oder dem neuen Standard zertifiziert werden. Für Unternehmen, die neu anfangen ist es ratsam sich direkt an der Version 2022 zu orientieren. Somit lässt sich festhalten, dass sich der Umfang der Änderungen für bereits zertifizierte Unternehmen im Rahmen hält und diese besser gleich umgesetzt werden sollen. Der Aufwand für Unternehmen, die bislang die Punkte des Anhangs lediglich abgehakt haben ist jedoch um ein vielfaches höher. Insbesondere die Überarbeitung der SoA (Statement of Applicability), welche die Maßnahmen zur Behandlung von Risiken auflistet und beschreibt, nimmt einige Zeit in Anspruch. Ebenso müssen die in der Risikoanalyse festgestellten Risiken mit wirksamen Maßnahmen verknüpft werden. Darüber hinaus ist es wichtig alle in der Norm enthaltenen Anforderungen zu bearbeiten. Sollten bestimmte Anforderungen nicht zum Unternehmen passen muss hierzu eine Begründung abgegeben werden, weshalb diese nicht für das Unternehmen relevant sind.
Abschließend ist zu beachten, dass die tatsächlichen Auswirkungen der Revision auf Unternehmen von verschiedenen Faktoren abhängig sind. Daher wird empfohlen, sich mit einem Experten für Informationssicherheit Verbindung zu setzen, um die genauen Auswirkungen der ISO 27001:2022 auf Ihr Unternehmen zu ermitteln und geeignete Maßnahmen umzusetzen.
von Michael Wager | Feb 10, 2023 | Cyber-Sicherheit
by Michael Wager
Containers have become an essential part in modern software development. The technology greatly simplifies and enhances the way software is developed and deployed to production. DevOps – the combination of development and operations would be hard without them. This success leads to a giant number of public container image repositories and unfortunately also potential issues regarding security. Most of these containers contain many components not needed in production (e.g. shells, package managers, binaries/files with special permissions etc) and these components often have high or even critical vulnerabilities which could be exploited by malicious attackers. This report from Sysdig claims „that 75% of containers have “high” or “critical” patchable vulnerabilities“.
This blogpost will give a quick introduction to container security best practises and also looks at an interesting approach to reduce the attack surface by removing not needed components. It does not matter if you are using Kubernetes (K8s) or running your containers inside a public or private cloud.
Best practises
Typical vulnerabilities related containers are for example related to older – and therefore vulnerable – versions of docker (e.g.
directory traversal) or vulnerabilities related
binaries installed inside the image (See
this link from snyk for more information about Docker Security – Challenges & Best Practices.) Also, snyk is the
default scanner used behind the scenes when executing `docker scan`.
Example output of a critical container vulnerability affecting the curl package from executing `docker scan`
Although container security is a complex topic, fortunately there are certain low hanging fruits which are very easy to implement and can have large impact on security. Let’s have a look at some of them.
1. Do not run your containers as root
Docker containers run as root by default. But by using the USER command in your Dockerfile it is quite simple to switch to a non-root user.
2. Use Secure Container Registries
Just like as described in our post about vulnerable components inside your software supply chain, there may be vulnerable container images in certain public registries. Therefore you should only use trusted registries or even better, your own private registry.
3. Use minimal base images
There are images like „slim“ or „alpine“ you may use as base. They contain way less components than the large full blown default images and are therefore reducing the attack surface. Canonical, for example, provides Ubuntu base images free from high or critical vulnerabilities in a timely manner – commercial support from other vendors might also be an option in your organisation. The less components an image contains, the lower the likelihood of severe vulnerabilities.
4. Scan your containers for vulnerabilities
There are tools which scan your images for known vulnerabilities. You should use them and consider to fail the pipeline, e.g. in case there are high or critical findings. Some tools you could consider:
- Trivy (Open source, free)
- Snyk (Free for 100 tests / month)
- PrismaCloud and twistcli (Enterprise ready)
5. Monitor your containers in production
After your containers are running in production, new vulnerabilities may be found. That’s why you should also monitor your containers and get notified when new vulnerabilities are discovered.
Unfortunately, scanners often report a lot of findings and false positives (or vulnerabilities that aren’t actually a risk to your specific software or service). It can be hard to decide if vulnerable components are really an issue. A better approach would be not to install so many components in the first place. Enter „distroless“!
6. Consider „Distroless“ images
A very interesting concept is coming from google and is called „distroless„. What they mean by distroless are images that contain only the application code and its runtime dependencies. The open source project provides ready to use images for Java, Node.js, C# and Python. Others may be built using either their „static“ base images or using google’s build tool Bazel. So you get small, production-ready images with only the dependencies you need, but it is important to note that development teams have to have very good knowledge about the underlying functionality of a linux system when using distroless. For example, a node.js application with a dependency to a glic based binary needs the app team to make certain non-trivial changes to the image build process. Another example regarding the PHP runtime, it can get quite complex when it comes to building your own images using Bazel. Other projects like “Chisel” from Canonical, the open source project behind Ubuntu, are currently trying to take this appoach to the next level. We have consulted companies regarding this topic and brought secure distroless images to production.
Conclusion
Just because your applications are running in containers does not mean they are secure – but there are simple ways to add more security. For our customers, we are always looking for efficient solutions to automate as much as possible and to shift security left. Our security experts can consult you on the topic and also help you selecting and integrating container scanning tools into your development lifecycle.
If you have questions, contact us at cybersecurity@secure-io.de
