Bästa tillvägagångssätt för att hantera säkerhetstillbud

Engagera systemintegratören och lämplig säkerhetspersonal för att genomföra utredningar och åtgärder.

Bestäm omfattningen av attacken:

• Användes kreditkortsinformation?
• Vilken information stals?
• Hur lång tid har gått sedan kompromissen?
• Krypterades informationen?

Försök att hitta attackvektorn för att avgöra när och hur platsen komprometterades genom att granska serverloggfiler och filändringar.

• Under vissa omständigheter kan det vara tillrådligt att svepa och installera om allt eller skapa en ny instans om det är en virtuell värdtjänst. Skadlig kod kan döljas på en plats som inte misstänks, bara i väntan på att återställas.

• Ta bort alla onödiga filer. Installera sedan om nödvändiga filer från en känd, ren källa. Du kan till exempel installera om med hjälp av filer från versionskontrollsystemet eller från de ursprungliga distributionsfilerna från Adobe.

• Återställ alla autentiseringsuppgifter, inklusive databas-, filåtkomst-, betalnings- och leveransintegreringar, webbtjänster och administratörsinloggning. Återställ även alla integrerings- och API-nycklar och konton som kan användas för att attackera systemet.

Granska administratörsåtgärdsloggar.

Rapporten Åtgärdsloggar innehåller en detaljerad beskrivning av alla administratörsåtgärder som har aktiverats för loggning. Varje post är tidstämplad och registrerar användarens IP-adress och namn. Logginformationen innehåller administratörsanvändardata och relaterade ändringar som gjordes under åtgärden.

Analysera händelser med verktyget Observation for Adobe Commerce.

Med verktyget Observation for Adobe Commerce kan du analysera komplexa problem för att identifiera rotorsaker. Istället för att spåra olika data kan ni lägga tid på att korrelera händelser och fel för att få djupare insikter i orsakerna till flaskhalsar i prestandan.

Använd fliken Säkerhet i verktyget för att få en tydlig bild av potentiella säkerhetsproblem som hjälper till att identifiera rotorsaker och se till att webbplatserna fungerar optimalt.

Analysera loggar med New Relic-loggar

Adobe Commerce i molninfrastrukturproprojekt innehåller tjänsten New Relic Logs. Tjänsten är förkonfigurerad för att samla alla loggdata från dina miljö för förproduktion och produktion och visa dem på en central kontrollpanel för logghantering där du kan söka efter och visualisera aggregerade data.

För andra Commerce-projekt kan du konfigurera och använda tjänsten New Relic Logs för att utföra följande uppgifter:

• Använd New Relic-frågor för att söka efter aggregerade loggdata.
• Visualisera loggdata via programmet New Relic Logs.

Granska administratörsanvändaråtkomst - Ta bort gamla, oanvända eller misstänkta konton och rotera lösenord för alla administratörsanvändare.

Granska säkerhetsinställningarna för administratörer - Verifiera att säkerhetsinställningarna för administratörer följer god säkerhetspraxis.

Granska användarkonton för Adobe Commerce i molninfrastrukturprojekt - Ta bort gamla, oanvända eller misstänkta konton och rotera lösenord för alla användare i molnprojektadministratören. Kontrollera att kontosäkerhetsinställningarna är korrekt konfigurerade.

Granska SSH-nycklar för Adobe Commerce i molninfrastruktur - Granska, ta bort och rotera SSH-nycklar.

Gå till konfigurationen HTML för sidhuvud och sidfot i Admin i alla omfångsnivåer, inklusive website och store view. Ta bort okänd JavaScript-kod från skript och formatmallar samt olika HTML-inställningar. Behåll endast identifierad kod som spårningsfragment.

Jämför den aktuella produktionskodbasen med kodbasen som lagras i Version Control System (VCS).

Karantän all misstänkt kod.

Se till att det inte finns några kvar misstänkt kod genom att omdistribuera kodbasen till produktionsmiljön.

Granska alla lagrade procedurer för ändringar.

Kontrollera att databasen bara är tillgänglig för Commerce-instansen.

Kontrollera att det inte längre finns någon skadlig kod genom att skanna webbplatsen med offentligt tillgängliga skanningsverktyg för skadlig kod.

Skydda administrationspanelen genom att ändra dess namn och verifiera att URL:erna för webbplatsen app/etc/local.xml och var inte är tillgängliga för alla.

Fortsätt att noga övervaka webbplatsen efter incidenten eftersom många webbplatser på nytt komprometteras inom några timmar. Se till att logggranskningen och filintegritetsövervakningen sker kontinuerligt för att snabbt upptäcka tecken på nya kompromisser.