Security Professionals - ipfw add deny all from eindgebruikers to any

SOC & Sourcing

12-10-2012, 17:08 door Sammy, 5 reacties
Een Security Operations Center is een mooi model om de beveiliging in een bedrijf te centraliseren, security informatie bij elkaar te brengen en 24/7 monitoring te realiseren, om zodoende veel adequater te kunnen reageren op bedreigingen en incidenten.

De literatuur vertelt veel over technieken (SIEM, IDS/IPS, AV, Access, ...), over mensen en hun competenties en over processen in het kader van incidentafhandeling.

Waar ik zelf lastig de vinger achter krijg en waar ik niets over heb kunnen vinden is hoe een SOC zijn informatie zou moeten krijgen van een sourcing partner waar een deel van het beheer van applicaties, hardware of een dienst is uitbesteed.

Als een SOC in staat moet zijn (vrijwel) instantaan te reageren op bedreigingen hoe los je dat dan op met externe leveranciers die zich niet zomaar in de keuken laten kijken.

Heeft iemand ervaring of ideeen hierbij, wat kun je technisch regelen, wat is te regelen met afspraken en SLA's en waar moet je accepteren dat er een vertraging ontstaat in je responsetijden?

Thx.
Reacties (5)
12-10-2012, 17:20 door SirDice
In jouw SLA zul je rekening moeten houden met het feit dat je soms afhankelijk bent van derde partijen. En natuurlijk moet je ook goede SLA afspraken maken met die partijen. Verder kun je natuurlijk ook in je SLA zetten dat je een bepaalde service, uit voorzorg, uit de lucht haalt totdat die andere partij (waar jij weer afhankelijk van bent) met een oplossing komt.

Overigens is er ook een verschil tussen responstijd en oplostijd. Je kunt best snel reageren (responstijd) maar later pas een echte oplossing bieden.
12-10-2012, 17:43 door Anoniem
Sammy,

Inderdaad een lastig vraagstuk.
Je kunt in principe nooit een derde partij vertrouwen.
Daarom zijn cloud en saas oplossing beveiligingstechnisch een draak.
De oplossing die ik doorvoer is zoveel mogelijk alles binnen de organisatie houden.
Dat gaat helaas niet van de een op de andere dag.
Ik zou je adviseren je SIEM oplossing dusdanig te configueren zodat je security en audit logs inzichtelijk kunnen maken waar deze partijen toegang tot hebben gehad.

Dan kun je ze aansprakelijk stellen in geval van nare gevolgen. Dat moet je dan wel in de SLA vastleggen uiteraard.
14-10-2012, 15:56 door wica128
responstijd, is meestal nooit een probleem. Een automatisch reactie is al vaak voldoende (hoe lullig het ook klinkt)

Vervolgens, als je met meerdere partijen moet samen werken, dat heb je met alle partijen een overeenkomst. Met daar in de contact nummers en personen van de des betreffende bedrijven.

Mijn ervaring met de overheid is, als volgt.
Ik ben eerste aanspreek punt, aangezien ik ook het beheer doe van de server.
Als ik een probleem zie. Gaat er als eerste een email uit naar een gezamelijk email adres.
Vervolgens onderzoek ik waar het probleem zich afspeelt. Dit zie je vaak snel genoeg.

Vervolgens coördineer, ik de te nemen acties. Dus de des betreffende mensen (wakker) bellen en er zorg voor te dragen, dat deze mensen hun werk gaan doen.

Ondertussen word elke actie, via het gezamelijke email adres, vermeld.

Tot het probleem opgelost is. Welke ook weer gemailt wordt.

Vervolgens, stap je over op de vervolg proceduren. Het uitzoeken waarom het probleem ontstaan is, wat er gedaan is, en hoe het inde toekomst voorkomen kan worden (als dit mogelijk is)

Dit rapport gaat vervolgens weer naar alle partijen.

Daarna, ga de de opdrachten die, vanuit het rapport naar voren komen (mits de klant er mee eens is) monitoren, zodat deze tijdig opgepakt worden.


De kern van dit verhaal is. Je heb 1 partij nodig, die de verantwoording neemt, om alle andere partijen aan te sturen.

Deze proceduren neem je op in je SLA. En ja, er is actieve toezicht nodig, om er voor te zorgen dat alle partijen zich aan de SLA houden!
14-10-2012, 17:29 door Anoniem
Dat is op twee manieren te realiseren, en moet per definitie contractueel vastgelegd om belangenverstrengelen en privacy gevoelige kwesties alsmede verantwoordelijkheidskwesties te voorkomen.

1. Omlijnen van verantwoordelijkheden, daarmee vanuit gedeelde dreigingsovereenkomsten bedrijfspolitiek realiseren.
2. Omlijnen van resultaatverwachting tbv controle mechanismen

Zo'n SOC moet dus ten alle tijde;
1. haar informatie niet via een enkele bron bekomen
2. op alle mogelijke manieren deze informatie bekomen alsmede en door verificatie/controle waarbij actualiteit (dus snelheid) als prioriteitsmaatstaf dient.

Als de leverancier zich niet in de keuken wil laten kijken, neemt deze de verantwoordelijkheid en ook informatievoorziening hierin eigenlijk over. In het kader incident response zeg maar.

Wensen gaan samen met plichten. Ook en met name in een bedrijf waar deze veredelde vorm van risk management wordt toegepast, noodzakelijk is dan wel problemen ondervindt. Of wensen (ook relateerbaar aan service perspectief) worden pretenties en snel te kostbaar voor kwaliteit. Dus omzetgarantie ten koste van kwaliteit. Of onwil/onkunde in erkenning / acceptatie / omlijning van demand/probleem.

Dat het niet altijd gebeurd, heet gebrek aan leiderschap. Kan alleen maar door een teveel aan geld, tijd en verschuiving van kwaliteit/waarheid naar omzet/monopolie. Ingraven in plaats van innoveren.
20-10-2012, 12:24 door WhizzMan
Dit soort overeenkomsten zijn altijd maatwerk. Je zult per dienst/produkt moeten gaan kijken wat de risico's en impact zijn van onderbrekingen, vertragingen, exposure of datacorruptie.

Een aantal dingen die je mee wilt nemen:

- In de SLA niet alleen de first qualified response (iemand die diagnose kan doen, niet een automailer dat je ticket is aangemaakt) maar ook de oplossingstijd voor problemen moet worden benoemd. Je kan incidenten een niveau geven, waarbij je bijvoorbeeld een spelfoutje een lagere prioriteit en langere oplossingstijd geeft dan een gehackte server. Dit is iets wat je op maat voor de afgenomen diensten en producten zal moeten specificeren. Om zoiets goed te doen, zal je eerst je analyses moeten doen over risico en impact.

- Zorg er voor dat er governance is. Afspraken zijn mooi, maar er moet op worden toegezien dat ze worden nageleefd. Doe security audits, test je failover, backups teruglezen, al dat soort dingen. Als er dingen niet in orde zijn, moet je in je SLA hebben benoemd wat daar de gevolgen van zijn. Mensen beterschap laten beloven zonder verdere maatregelen is niet voldoende helaas. Zet er boetes op, mogelijkheden om contracten eenzijdig te beeindigen of wat dan ook passend is in jouw specifieke situatie. Zorg er wel voor dat de maatregelen proportioneel zijn, anders krijg je rechtszaken die je verliest inplaats van een oplossing voor je probleem.

Mijn tip in deze is: neem een partij in dienst die je begeleid in dit soort dingen netjes inregelen. Zorg er voor dat het belang van die partij niet is om hun vriendjes de hand boven het hoofd te houden, maar dat ze onafhankelijk zijn van jouw leveranciers. Op die manier zal die partij z'n best doen om het geld wat jij neertelt zo goed mogelijk te besteden. Er zijn professionals te huur die dit soort dingen regelmatig gedaan hebben die er veel meer ervaring in hebben dan jij. Ze kosten geld, maar vaak pak je dat makkelijk terug doordat de kwaliteit van de dienstverlening die jij van je leverancier afneemt een stuk omhoog gaat. Zeker als je een wat groter bedrijf bent en "grote" diensten afneemt, zijn de kosten van een enkel incident soms al hoger dan zo'n deskundige hulp je kost bij het opstellen van de SLA.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.