Vorig jaar schreef ik voor het Cqure Kennisplatform een artikel over: “Zinvol gebruik van security metrics” (zie artikel op kennisplatform Cqure).

Ik heb gemerkt dat er behoefte blijkt te zijn aan een praktijkvoorbeeld. Daarom besteed ik dit artikel aan een rekenvoorbeeld om de security metrics van een webserver te bepalen. Daarna gebruik ik de metrics om te bepalen wat voor impact verwacht mag worden van verschillende aanvullende maatregelen, zodat het beschikbare budget optimaal ingezet kan worden. Voor een beknopte uitleg over de achterliggende theorie verwijs ik u naar het eerdere artikel.

Beschrijving situatie

Bij het onderzoek van een webserver blijken er services beschikbaar te zijn op de TCP poorten 80 en 443. Het systeem reageert op geen enkele manier op andere TCP-poorten en reageert ook niet op ander IP-protocollen, zoals bv. UDP en ICMP. Op poort 80 /tcp wordt een webservice aangeboden. Eén van de HTTP response-headers is: Server: Apache/2.2.19 (Win32) PHP/5.2.17 Op poort 443 /tcp wordt een webservice over SSL en TLS aangeboden. Het HTTPS protocol ondersteunt de protocollen: SSLv2, SSLv3, TLSv1.0 en TLSv1.1. Verder ondersteunt de server cipher suites met sleutellengten van 40 en 56 bits, maar gelukkig ook sterkere sleutels. Het SSL certificate is een zogenaamd self signed certificate en is twee maanden verlopen. Een andere HTTP response-headers op poort 443 /tcp is: Via: 1.1 Cerberus.

Analyse

Het systeem reageert met open poorten 80 /tcp en 443 /tcp. Het systeem is toegankelijk op 2 poorten, dus tellen we: 2x access. Omdat het systeem reageert, is het ook zichtbaar, dus: 1x visibility

Het systeem reageert niet op andere TCP-poorten en IP-protocollen. Volgens verschillende RFC’s hoort de server de client te informeren als er wordt gepoogd om met een gesloten poort te verbinden. Omdat die informatie niet wordt ontvangen, wordt dit verkeer tegengehouden door een firewall of een ander beveiligingsapparaat. We tellen dit als 1x authentication voor elke access die beschermd wordt, dus: 2x authentication

Op poort 443 /tcp wordt een dienst aangeboden met het HTTPS protocol. HTTPS levert encryptie (=vertrouwelijkheid) en detecteert als de onderhandelingen over de encryptie-sleutel worden gewijzigd door een derde partij. Bovendien ontneemt het de vrijheid van de bezoeker om via het onveilige protocol HTTP te communiceren. Daarom tellen we deze waarneming als: 1x confidentiality, 1x integrity en 1x subjugation.

De versienummers van Apache en PHP zijn gelekt. Een aanvaller hoeft nu maar te onderzoeken of er gedocumenteerde kwetsbaarheden zijn van die versies en als die er zijn, dan kan daar misbruik van gemaakt worden. Vaak zijn de exploits gewoon on-line te vinden. Deze waarneming telt als: 2x exposure.

Het SSL certificate is self signed en twee maanden verlopen. Het SSL certificaat levert bewijs van de identiteit van van server aan de client. Dit kan meetellen als een authentication en een non-repudiation control. Echter, het bewijs over de identiteit van de server beschermd wel de bezoeker, maar niet de server zelf. En dit voorbeeld gaat over de veiligheid van de server (zie inleiding). Omdat het certificaat geen bescherming biedt aan de server, wordt deze waarneming niet meegeteld om de rav van de server te bepalen. Als we de rav van de bezoeker bepalen, zou deze waarneming meetellen als 1x weakness (kwetsbaarheid in authentication) en 1x concern (kwetsbaarheid in non-repudiation).

Het SSLv2 protocol heeft enkele ernstige tekortkomingen. Het gebruik van SSLv2 wordt sinds 1996 afgeraden. Op 14 oktober 2014 is ook een ernstige tekortkoming van SSLv3 gepubliceerd en wordt ook het gebruik daarvan ontraden. We tellen dit als: 2x concern (limitation van confidentiality en integrity).

Sleutels met lengtes van 40 en 56 bits konden in de vorige eeuw al binnen relatief korte tijd gekraakt worden. Zij moeten daarom niet gebruikt worden om vertrouwelijke gegevens te beschermen. We tellen dit als: 1x concern (weak ciphers).

Eén van de response headers voor port 443 /tcp is: Via: 1.1 Cerberus. De Via-header wordt toegevoegd door (reverse) proxyservers. Een (reverse) proxyserver levert privacy en soms ook authentication. We tellen dit als: 1x privacy. We tellen deze control maar één keer, omdat de reverse proxyserver alleen bij poort 443 is gedetecteerd en niet bij poort 80. Er is nu een reverse proxyserver ontdekt. Als er interacties mogelijk zijn met deze reverse proxyserver, dan is er een extra systeem ontdekt in de scope. We verhogen dan de de visibility met één en ook het aantal accesses neemt toe met één of meer. We hebben alle waarnemingen nu gekoppeld aan metrics voor porosity, controls en limitations.

Dit zijn de waarden we hebben vastgesteld:

• 2x access – poorten 80 /tcp en 443 /tcp
• 1x visibility – systeem reageert
• 2x authentication – firewall gedetecteerd
• 1x confidentiality – gebruik van HTTPS
• 1x integrity – gebruik van HTTPS
• 1x subjugation – gebruik van HTTPS
• 2x exposure – versienummers van Apache en PHP zijn gelekt
• 2x concern – toestaan van SSLv2 en SSLv3
• 1x concern – toestaan van weak ciphers
• 1x privacy – reverse proxy server

Uit de spreadsheet blijkt dat het resultaat een rav is van ca. 86.5. Dat is niet best! Realiseer dat een rav van 80 op matige security wijst. Een rav boven 90 is doorgaans voldoende, boven 95 is goed en en boven 98 is zeer goed.

Verbeteren van de security

We willen de security verbeteren en dat kan door de rav te verhogen. De eerste stap is het verhelpen van de limitations. De limitations zijn negatieve effecten van implementatiefouten en zijn vaak eenvoudig te verhelpen door het systeem beter te configureren. De rav schiet omhoog en in het algemeen is de investering gering, zowel in geld als in tijd. Nadat Apache zo geconfigureerd is dat het geen versienummers meer toont, geen SSLv2 en SSLv3 ondersteunt en geen weak ciphers meer gebruikt, zijn alle limitations verholpen. De rav is nu gestegen naar ruim 96.8.

Als we het beveiligingsniveau zo voldoende vinden, dan kunnen we hier stoppen. Maar als we een hoger beveiligingsniveau nastreven, dan kunnen we nu “wat-als”-analyses uitvoeren. Hiermee bepalen hoeveel de veiligheid toeneemt bij verschillende oplossingsalternatieven, maar nog voor we er geld aan hebben uitgegeven. Door de resultaten te vergelijken, kunnen we bepalen waar we ons budget het best aan kunnen besteden.

Voorbeelden zijn:

1. voer het systeem redundant uit; dit levert +1x continuity – rav 97.1
2. of gebruik een IDS (Intrusion Detection System); dit levert +1x alarm – rav 97.1
3. of gebruik een IPS (Intrusion Detection System); dit levert +1x alarm en +1x authentication – rav 97.3
4. of combineer oplossingen, bv. redundantie en IPS; rav 97.5

Deze voorbeelden tonen al dat er in deze situatie twee verschillende oplossingen zijn, redundantie of het gebruik van een IDS, die de veiligheid in gelijke mate verhogen. Als je budget beperkt is, kun je hier dus kiezen voor de goedkoopste van de twee oplossingen. Let op dat deze conclusie alleen geldt voor deze situatie en dat je die niet mag generaliseren. In andere situaties, met andere eigenschappen en andere getallen, is het goed mogelijk dat één van deze twee oplossingen een veel grotere impact heeft dan de andere. Deze voorbeelden tonen ook aan dat de laatste puntjes het moeilijkst zijn te verkrijgen. Je zult zien dat het op een bepaald moment heel duur gaat worden om de veiligheid verder te verhogen.

Vulnerability scan en penetratietest

Het verhelpen van de limitations komt overeen met het verhelpen van kwetsbaarheden die zijn gevonden gedurende een vulnerability scan of penetratietest. Het verder verhogen van de beveiliging komt overeen met aanbevelingen na een audit, een penetratietest of zelfs een gesprek met een sales-medewerker van een leverancier. Het voordeel van het gebrui van metrics is vooral dat je inzicht krijgt in hoeveel de veiligheid toeneemt. Je kunt dit inzicht gebruiken om herstelacties verstandiger te plannen en om te voorkomen dat je kapitalen gaat uitgeven, zonder dat het veel oplevert. Stel je voor dat je had gekozen voor het redundant maken van de omgeving en uitbreiden met IPS, maar de kwetsbaarheden niet eerst had verholpen. De rav zou dan maar gestegen zijn van 86.5 naar 87.2. De kosten en doorlooptijd hiervan zijn enorm veel hoger dan die voor het verhelpen van de kwetsbaarheden, terwijl de goedkopere maatregelen de veiligheid enorm doet stijgen.

Slotwoord

Ik hoop dat dit rekenvoorbeeld helpt te begrijpen hoe security metrics zinvol gebruikt kunnen worden. Als iets niet duidelijk is, laat het mij dan weten en ik probeer het alsnog uit te leggen. Of op een andere manier. En als je het niet met mij eens bent, laat dan je argumenten horen.