Niektórzy z naszej grupy infrastruktury chcą dokonać aktualizacji, aby zacząć korzystać z nowych funkcji RHEL 6. W przeszłości korzystałem z Przewodnika NSA (www.nsa.gov/ia/_files/os/redhat/rhel5-guide- i731.pdf) w celu zabezpieczenia instalacji RHEL 5 i CentOS 5. Uważam ten przewodnik za nieoceniony.
Czy ktoś ma doświadczenie w zabezpieczaniu RHEL / CentOS 6 w podobny sposób? Jeśli tak, jakie zasoby (pisemne lub konsultacyjne) wykorzystałeś?
Słyszałem od niektórych kolegów, że wersja 6 różni się znacznie od wersji 5 na różne sposoby, więc nie chcę pozostawiać luk w naszym bezpieczeństwie, ponieważ nie uwzględniłem odpowiednio tych różnic.
Czy własny przewodnik Red Hat dotyczący RHEL 6 ( http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html ) jest naprawdę wystarczający?
Czy ktoś posunąłby się nawet do stwierdzenia, że jeśli nie masz ważnego powodu funkcjonalnego, powinieneś wstrzymać się z aktualizacją z 5 do 6, aż jakaś grupa, taka jak NSA, może stworzyć przewodnik, który jest specyficzny dla wersji, którą próbujesz chronić?
Doceniam wszelkie opinie, które możesz mieć, nawet jeśli kierują mnie do bardziej odpowiedniego forum.
Pozdrowienia,
Mikrofon
źródło
Odpowiedzi:
Mikrofon,
ogólnie istnieje kilka źródeł dobrych przewodników dotyczących zwiększania bezpieczeństwa.
W mojej pracy używamy kombinacji DISA STIG, wraz z marionetką dla Linuksa. Bardziej prawdopodobne jest, że stwierdzę, że jest to nieodpowiednie, i postuluję skorzystanie z niektórych z poniższych zaleceń.
Należy pamiętać, że powyższe prowadnice utwardzania nakładają się i niektóre brakujące obszary. Najlepszą praktyką jest śledzenie wszystkich opcji konfiguracji za pomocą przewodnika w bazie danych lub arkuszu kalkulacyjnym, aby uzyskać jak największy zasięg.
Alternatywnym sposobem na zrobienie tego samego jest stworzenie skryptów hartujących lub audytujących w oparciu o powyższe, a następnie przeprowadzenie własnych audytów, aby dowiedzieć się, gdzie są luki między różnymi standardami.
Nie wierzę, że przewodniki RHEL są wystarczające - wolę wyniki NSA, DISA i NIST. Ale przewodniki Red Hata są świetnym punktem wyjścia.
Ponieważ NSA i DISA zaczynają prace nad standardami hartowania z dużym wyprzedzeniem, mogą one być dla Ciebie dobrym źródłem. Jeśli masz przyjaciela w DoD, możesz również uzyskać dostęp do materiałów przedpremierowych. Ze względu na obecny stan DISA STIG dla Red Hat powiedziałbym, że NSA prawdopodobnie wyprodukuje coś szybciej. Mogę się z nimi sprawdzić i sprawdzić, gdzie oni są. Polecam zacząć teraz przechodzić do 6 w środowisku testowym. Przetestuj swoje skrypty hartujące w wersji 6.
Angażowanie pomocy z zewnątrz w celu opracowania wytycznych dotyczących zwiększania bezpieczeństwa
Rozważ współpracę z Inżynierem ds. Bezpieczeństwa skoncentrowanym na wzmocnieniu bezpieczeństwa systemu Linux, aby uzyskać wskazówki. Red Hat może również udostępnić swoim pracownikom zlecenia, aby przyspieszyć działania inżynierów bezpieczeństwa.
Wszystko, co powiedziałeś do tej pory, wskazuje na zasadę należytej staranności i rozsądne bezpieczeństwo. W oparciu o to, myślę, że biorąc pod uwagę powyższe, możesz przejść do RHEL6. Jednak dodam kilka dodatkowych zadań, które możesz rozważyć, ponieważ zakładam, że pracujesz w środowisku regulowanym, które jest bardzo świadome bezpieczeństwa.
Rozszerz swoje podejście o ocenę ryzyka
Jeśli chcesz przenieść swoje podejście na kolejny poziom i uzasadnić go w taki sposób, że przejdzie kontrolę nawet przez najbardziej wybrednego audytora, rozważ przeprowadzenie pełnej oceny ryzyka rozwoju przy użyciu NIST 800-30 wraz z konkretnymi zestawami kontroli stosowanymi w twoim przemysł. To, wspierane przez testy i analizy bezpieczeństwa. Sformalizowanie oceny ryzyka pozwoli na dobrą dokumentację przedstawionych ryzyk poprzez kontynuację pracy z RHEL6, a także na niektóre potencjalne kontrole kompensacyjne, które można dodać, aby uzupełnić wszelkie potencjalne słabości.
Dodanie testu penetracji
Wykraczając nawet poza ocenę ryzyka, możesz zaangażować tester penetracji z silnym tłem dla Linuksa, aby spróbować penetracji białej skrzynki lub czarnej skrzynki na hoście RHEL6 po pewnych bezpiecznych konfiguracjach. Zabezpieczony podstawowy system operacyjny może nie wykazywać dużej powierzchni ataku, więc załadowanie go aplikacjami stanowiłoby znacznie bardziej realistyczną platformę ataku, która lepiej umożliwiłaby zrozumienie potencjalnych wektorów ataku. Krążąc na końcu, korzystając z raportu z testu pióra, możesz zwiększyć swoją poprzednią pracę, zamknąć wszelkie luki, dodać dodatkowe elementy sterujące i skierować się do operacji o wiele bardziej ciepłym i rozmytym.
źródło
Prace nad RHEL 6 STIGS zostaną ukończone około 13 maja 2013 r. Możesz śledzić informacje na liście mailingowej Red Hat Gov-Sec.
źródło