Einige Mitglieder unserer Infrastrukturgruppe möchten ein Upgrade durchführen, um die neuen Funktionen von RHEL 6 nutzen zu können. In der Vergangenheit habe ich mich auf den NSA-Leitfaden verlassen (www.nsa.gov/ia/_files/os/redhat/rhel5-guide- i731.pdf) zum Sichern von RHEL 5- und CentOS 5-Installationen. Ich finde diesen Leitfaden von unschätzbarem Wert.
Hat jemand Erfahrung mit der Sicherung von RHEL / CentOS 6 auf ähnliche Weise? Wenn ja, welche Ressourcen (schriftlich oder beratend) haben Sie eingesetzt?
Ich habe von einigen Kollegen gehört, dass Version 6 in verschiedener Hinsicht erheblich von Version 5 abweicht, daher möchte ich keine Lücken in unserer Sicherheit hinterlassen, da ich diese Unterschiede nicht ausreichend berücksichtigt habe.
Reicht Red Hats eigener Leitfaden für RHEL 6 ( http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html ) wirklich aus?
Würde jemand so weit gehen zu sagen, dass Sie, sofern Sie keinen zwingenden funktionalen Grund haben, das Upgrade von 5 auf 6 unterbrechen sollten, bis eine Gruppe wie die NSA einen Leitfaden erstellen kann, der spezifisch für die Version ist, die Sie schützen möchten?
Ich freue mich über jedes Feedback, das Sie haben, auch wenn es mich an ein geeigneteres Forum weiterleitet.
Grüße,
Mike
quelle
Antworten:
Mike,
Es gibt im Allgemeinen ein paar Quellen für gute Anleitungen zur Sicherheitshärtung.
Bei meiner Arbeit verwenden wir eine Kombination der DISA STIGs zusammen mit Puppet für Linux. Ich würde eher sagen, dass dies unangemessen ist, und auf einige der folgenden Empfehlungen drängen.
Beachten Sie, dass sich die oben genannten Härtungsführungen überlappen und einige Bereiche fehlen. Eine bewährte Methode besteht darin, alle Konfigurationsoptionen über eine Anleitung in einer Datenbank oder einer Tabelle zu verfolgen, damit Sie die größtmögliche Abdeckung erhalten.
Eine alternative Möglichkeit, dasselbe zu tun, besteht darin, Hardening- oder Auditing-Skripts auf der Grundlage der obigen Informationen zu erstellen und dann Audits bei Ihnen durchzuführen, um herauszufinden, wo die Lücken zwischen den verschiedenen Standards liegen.
Ich glaube nicht, dass RHELs Anleitungen ausreichen - ich bevorzuge die Ausgaben der NSA, DISA und NIST. Die Leitfäden von Red Hat sind jedoch ein guter Ausgangspunkt.
Da die NSA und die DISA weit im Voraus mit der Erarbeitung von Härtungsstandards beginnen, kann dies eine gute Quelle für Sie sein. Wenn Sie einen Freund in DoD haben, können Sie auch auf Vorab-Veröffentlichungen zugreifen. Aufgrund des aktuellen Status des DISA STIG für Red Hat würde ich sagen, dass die NSA wahrscheinlich etwas schneller produzieren wird. Ich kann mich bei ihnen melden und sehen, wo sie sind. Ich würde empfehlen, in einer Testumgebung sofort auf 6 vorzurücken. Lassen Sie Ihre Hardening-Skripte in 6 testen.
Unterstützung von außen zur Entwicklung sicherheitsrelevanter Leitlinien
Überlegen Sie, ob Sie einen Security Engineer beauftragen möchten, der sich speziell mit der Linux-Sicherheitssicherung befasst, um eine Anleitung für Sie zu erstellen. Red Hat kann seine Mitarbeiter auch für Einsätze zur Verfügung stellen, um die sicherheitstechnischen Bemühungen zu beschleunigen.
Alles, was Sie bisher gesagt haben, deutet auf einen Due-Diligence-Ansatz und angemessene Sicherheit hin. Ausgehend davon, denke ich, ist es klar, dass Sie zu RHEL6 übergehen werden. Ich werde jedoch einige zusätzliche Aufgaben hinzufügen, die Sie in Betracht ziehen könnten, da ich davon ausgehe, dass Sie in einer regulierten Umgebung arbeiten, die sehr sicherheitsbewusst ist.
Erweitern Sie Ihren Ansatz mit einer Risikobewertung
Wenn Sie Ihren Ansatz auf die nächste Ebene bringen und ihn so rechtfertigen möchten, dass er auch von den am wenigsten betroffenen Prüfern überprüft wird, sollten Sie eine umfassende Bewertung des Entwicklungsrisikos mit NIST 800-30 und den in Ihrem Test verwendeten Kontrollsätzen durchführen Industrie. Dies wird durch Sicherheitstests und -analysen unterstützt. Die Formalisierung einer Risikobewertung ermöglicht eine gute Dokumentation der mit RHEL6 verbundenen Risiken sowie einige potenzielle Ausgleichskontrollen, die Sie hinzufügen können, um potenzielle Schwachstellen zu beseitigen.
Penetrationstest hinzufügen
Selbst wenn Sie über die Risikobewertung hinausgehen, können Sie einen Penetrationstester mit starkem Linux-Hintergrund einsetzen, um nach einigen sicheren Konfigurationen White-Box- oder Black-Box-Penetrationen Ihres RHEL6-Hosts zu versuchen. Ein gesichertes Basisbetriebssystem bietet möglicherweise nicht viel Angriffsfläche. Wenn Sie es also mit Anwendungen laden, erhalten Sie eine viel realistischere Plattform für Angriffe, mit der Sie potenzielle Angriffsmethoden besser verstehen können. Mit dem Pen Test Report können Sie am Ende Ihre bisherigen Arbeiten ergänzen, Lücken schließen, zusätzliche Steuerelemente hinzufügen und den Betrieb mit viel mehr Wärme und Unschärfe ansteuern.
quelle
Die RHEL 6 STIGS werden voraussichtlich am 13. Mai 2013 fertig sein. Sie können den Informationen auf der Gov-Sec-Mailingliste von Red Hat folgen.
quelle