WHITEPAPER Veiligheid als belangrijk aspect van de software
Van cruciaal belang bij systemen die gekoppeld zijn aan het internet
Beveiligingsrisico’s
Door nieuwe toepassingen voor het verbinden van producten aan het internet, ontstaan nieuwe mogelijkheden voor al dan niet bestaande diensten. Helaas kleeft er ook een risico aan deze nieuwe toepassingen, namelijk de beveiliging en beschikbaarheid. Informatie die beschermd had moeten zijn kan beschikbaar worden gesteld aan vreemden, maar het kan ook zijn dat producten niet meer functioneren of zich anders gaan gedragen dan oorspronkelijk is bedoeld. Vooral bij bedrijfskritische software is het risico hierop groot.
Bij TASS vinden we veiligheid een bijzonder
gehouden met de beveiliging. Het brengt
belangrijk aspect van de software. In veel
onnodige kosten met zich mee wanneer
gevallen wordt hierover pas aan het einde
er in de productiefase nog fundamentele
van een ontwikkelproces nagedacht. De
aanpassingen gedaan moeten worden aan
oorzaak hiervan ligt in het feit dat producten
het systeem. Bovendien bespaart u veel
ontwikkeld worden en pas in een later
geld als uw organisatie op geen enkele
stadium gekoppeld worden aan het internet,
wijze negatief in de media genoemd wordt.
met het risico dat er geen rekening wordt
U streeft toch ook naar veilige software?
Nachtmerrie van elke fabrikant Een sprekend voorbeeld van een beveiligingsrisico bij een verbonden product is een pacemaker die voorzien is van een draadloze interface. Onlangs kwam dit in het nieuws voorzien van de opvallende koptitel: ‘Hacker kan
het apparaat met kwaadaardige code te herprogrammeren. Een firewall voor pacemakers voorkomt deze aanvallen.
massamoord plegen via pacemakerlek’. Een nachtmerrie voor elke fabrikant die zijn product op de markt brengt. Pacemakers en geïmplanteerde defibrillatoren zijn kwetsbaar voor draadloze aanvallen, waardoor tienduizenden mensen kunnen sterven. Een software worm zou namelijk de pacemaker met kwaadaardige code kunnen overschrijven en instellen om een fatale elektriciteitsschok te leveren. Pacemakers beschikken namelijk over een draadloze interface die ontworpen is om informatie te verzamelen en het apparaat te beheren. Het grootste probleem is dat de apparaten voor de authenticatie alleen naar de serienummers en apparaatcodes kijken. Het is eenvoudig om toegang tot het apparaat te krijgen door deze nummers en codes te enumereren. Voor een hacker is het dan mogelijk om
genoemde bestaat er ook een Stuxnet worm. Stuxnet zou ontwikkeld zijn om Iraanse ultracentrifuges te saboteren die gebruikt worden voor het maken van nucleaire brandstof. Deze worm verspreidt zich in eerste instantie via Microsoft Windows en komt daarna terecht op de apparatuur. De worm wijzigt de apparatuur waarmee de motoren van de centrifuges aangestuurd worden. Een directe verbinding met de apparatuur is daarbij zelfs niet noodzakelijk om toch een aanval op het systeem te kunnen uitvoeren.
Er zijn nog andere manieren om de beveiliging te omzeilen. Naast de reeds
De twee bovengenoemde problemen hadden voorkomen kunnen worden wanneer er vanaf het begin van het ontwikkelproces vroegtijdig en beter was nagedacht over de beveiliging van het systeem.
Beveiliging moet vroegtijdig in het proces worden ingezet
People, proces & technology zijn onlosmakelijk verbonden als het gaat om security Robbin van den Dobbelsteen en Robert-Jan Willems, beide security consultants binnen Total Specific Solutions, zien in de dagelijkse praktijk maar al te vaak dat security het sluitstuk vormt van een software-
blijkt deze informatie er helemaal niet te zijn. Ook ontbreken er duidelijke richtlijnen die ervoor zorgen dat systemen of applicaties veilig worden geprogrammeerd. Security moet in een vroegtijdige fase maar ook gedurende
of systeemontwikkeltraject.
het hele ontwikkeltraject geadresseerd.”
Ook worden er steeds meer systemen “verbonden” aan het internet, waarvan dit op voorhand nooit de bedoeling is geweest. Binnen de security praktijk worden zogenoemde ethical hackers gevraagd om systemen of ontwikkelde toepassingen te testen op veiligheid voordat deze in productie worden genomen. Willems vertelt : “De eerste vraag die wij dan altijd stellen voorafgaand aan een dergelijke test luidt: Wat zijn de security eisen die in de requirementsfase van het ontwikkelingstraject zijn bepaald? En wat is het gewenste of noodzakelijke niveau van veiligheid waaraan het systeem zou moeten voldoen? Vaak blijft het dan stil of
worden
“Helaas blijkt uit de praktijk dat het niet automatisch goed gaat”, vervolgt Van den Dobbelsteen. “Dit leidt tot veel bevindingen op het gebied van security voortkomend uit onze security tests en ethical hacking opdrachten. Kwetsbaarheden in systemen vormen onacceptabele risico’s, die eerst verholpen moeten worden om veilig gebruik in de operationele/ productiefase van een systeem te kunnen garanderen. Afhankelijk van het type bevinding of kwetsbaarheid, kan het zijn dat enkele fixes of updates aan het systeem of aan de applicatie niet toereikend zijn en dat zelfs een gehele architectuur of ontwerp moet worden aangepast of herzien. Dit
Wat zijn uw security eisen in de requirementsfase?
kan hoge kosten met zich meebrengen. Ongeschreven regel is dat hoe later security in het traject wordt meegenomen, hoe duurder het is.“ Willems gaat verder: “Niet alleen voorkomt vroegtijdig nadenken over veilige software veel ellende, onderzoek toont aan dat tijdig rekening houden met security aspecten (“Security by design”) ook kan besparen op de Total Cost of Ownership (TCO) van een systeem, applicatie of toepassing. In de meeste software ontwikkeltrajecten ligt, ongeacht de gebruikte methodiek zoals bijvoorbeeld Waterval of Agile, de nadruk op de functionele eisen en wensen. De functionele eisen en wensen worden vooraf afgewogen en geprioriteerd tot de specificatie van het gewenste product is gevormd. Het is zaak om dit ook te doen voor security eisen. Het is raadzaam om vooraf een duidelijke afweging te maken tussen risico’s en de beveiligingseisen van een systeem, applicatie of toepassing. Van belang hierbij is om de risico’s, het nut en de noodzaak te evalueren in verhouding tot de kosten om zo tot de juiste keuze
(en het gewenste niveau van veiligheid) te komen. Common Criteria, een framework wat gebruikt wordt door TASS, borgt het proces van (security) specificatie, (secure) implementatie en zorgt voor een herleidbare evaluatie van de gevraagde security requirements achteraf. Dankzij Common Criteria is ook achteraf, na realisatie , op een duidelijke en gestandaardiseerde manier na te gaan wat het niveau van veiligheid van het betreffende systeem is.” “Security gaat verder dan alleen techniek”, meent Van den Dobbelsteen. “Andere factoren zijn net zo belangrijk voor het optimaal inrichten en effectief uitvoeren van (IT) security. Ons credo is dat People, Proces & Technology aspecten zijn die onlosmakelijk met elkaar verbonden zijn wanneer je het hebt over security. Het veilig creëren en het veilig houden van een systeem, applicatie en toepassing lukt alleen door de balans te vinden tussen bewust en veilig gebruikersgedrag, effectieve beveiligings- en beheersprocessen en veilig ontwikkelde technologie.”
‘Vroegtijdig nadenken over veilige software voorkomt ellende achteraf.’ Beveiliging vanuit de verdediging De opkomst van smartphone en tablet heeft ervoor gezorgd dat veel mensen continu met internet verbonden zijn. Hierdoor neemt de vraag toe om ook onze leefomgeving slimmer te maken. Steeds meer apparaten moeten gaan beschikken over de mogelijkheid om met andere apparaten te communiceren. Nu ook steeds meer bedrijfskritische apparaten via internet communiceren, wordt beveiliging steeds belangrijker. Bij medische producten kunnen we ons geen fouten veroorloven, net als in de autobranche waarbij grote consequenties voor de veiligheid kunnen optreden. Belangrijk is dat niet alleen nieuwe, maar ook reeds bestaande software goed beveiligd wordt. Meestal wordt beveiliging bekeken vanuit de aanvalskant. Een betere uitgangspositie is om dit te bekijken vanuit de verdediging, vanuit het startpunt van de ontwikkeling. Hoe later in het ontwikkelproces, hoe duurder het is om een wijziging door te voeren. Een architectuur
moet om die reden op hoofdlijnen in een keer goed opgezet worden waardoor de risico’s rondom de beveiliging al van tevoren geanalyseerd worden. Rekening houden met beveiliging tijdens het gehele ontwikkelproces kan aan de hand van het Common Criteria framework. Common Criteria is een internationale standaard (ISO/IEC 15408) waarmee klanten en eindgebruikers functionele- en beveiligingseisen opstellen door het toepassen van een Protection Profile (PP). Software ontwikkelaars kunnen aan de hand hiervan het systeem op een veilige manier implementeren en gefundeerd uitspraken doen over de veiligheid ervan. Uiteindelijk zal het systeem geëvalueerd worden door een onafhankelijke instantie om te bepalen of er daadwerkelijk voldaan is aan de eisen die gesteld zijn in het PP.
De praktijk Bij toegangscontrole speelt veilige serversoftware natuurlijk een belangrijke rol. Daarom heeft TASS bij het bouwen van een toegangscontrolesysteem Common Criteria gebruikt en tijdens de ontwikkeling de nadruk gelegd op het analyseren van alle beveiligingsrisico’s in het systeem. Eerst werden de onderdelen gedefinieerd die behoren tot het te evalueren doel. Dit wordt in Common Criteria de ‘Target of Evaluation’ genoemd, afgekort de TOE (zie ook figuur 1). Deze definitie en het opstellen van een Protection Profile bevindt zich in de requirementsfase van het project, in dit geval het Access Control System (ACS). Vervolgens worden in de designfase de functionele beveiligingseigenschappen bepaald in de vorm van een Security Target aan de hand van de beveiligingseisen uit het PP.
Common Criteria als basis van een goede beveiliging CASE
Access Control System
Het Access Control Sytem maakt het mogelijk om met behulp van een NFC tag toegang te krijgen tot een afgeschermde locatie. Bij deze oplossing kan er toegang verleend worden door een persoonlijke NFC tag te scannen op een mobiel apparaat dat is gekoppeld aan de deur (ook wel toegangspoort genoemd binnen het systeem). Na het scannen van de NFC tag zal de applicatie (app) op het mobiele apparaat automatisch gestart worden en een bericht versturen naar de server in de cloud. De server ontvangt dit bericht en zal toegang verlenen door de toegangspoort te openen, mits dit bericht uiteraard voldoet aan de gewenste eisen. De server zal het resultaat, wel of geen toegang, terugkoppelen aan het mobiele apparaat die dit dan zal weergeven op het scherm.
Het Target of Evaluation voor het Access Control System bestaat uit de server software, de PostgreSQL database en de communicatie (definitie van verschillende rollen). Daarnaast vormen ook de client software op het mobiele apparaat en de NFC data op de NFC tag onderdeel van de TOE. Deze onderdelen, zoals schematisch afgebeeld in figuur 1, bevinden zich binnen het roze kader. Het ACS van TASS bestaat uit een server en diverse mobiele apparaten. Op de server kun je met een website rollen, groepen, NFC tags en toegangspoorten beheren. Een beveiligingsrisico hierbij is dat de rol van een groep niet correct gedefinieerd is, waardoor een aantal personen toegang verleend wordt die dat eigenlijk niet hadden moeten krijgen.
Het is dus belangrijk om de diverse rollen correct te configureren. De onderdelen die niet door TASS ontwikkeld zijn behoren in dit geval niet tot de Target of Evaluation. Om toch het totale systeem goed te beveiligen dienen afspraken gemaakt te worden als het gaat om patchmanagement van bijvoorbeeld Apache webserver, Ruby on Rails, firewall en de hardware. Om het ACS te beveiligen wordt er gewerkt met SSL certificaten. Een SSL server certificaat maakt het mogelijk om te verifiëren of er inderdaad een verbinding is met de gewenste server. SSL zorgt ook voor encryptie, zodat de communicatie tussen beide partijen versleuteld is.
TOE is het meest kritische onderdeel bij beveiliging Private (TASS) cloud
Access Control System
Entrance
Apache
Hardware
Ruby on Rails
Firewall
Hardware
Target of Evaluation
Server Software
Roles
Mobile Device
Webclient
Hardware
Hardware
Client Software
Webbrowser
NFC tag
NFC data
PostgreSQL Database
Figuur 1: TOE Access Control System
Het Access Control System maakt het mogelijk om met behulp van een NFC tag toegang te krijgen tot een afgeschermde locatie.
De verbinding voor het vragen van toegang tot een toegangspoort op de server is extra beveiligd met een clientcertificaat. Omdat mobiele apparaten erg kwetsbaar zijn qua beveiliging is ieder apparaat voorzien van een eigen, uniek clientcertificaat. Dit maakt het mogelijk om een specifiek mobiel apparaat op ieder moment de toegang tot het systeem te ontzeggen. Hiermee wordt de toegangscontrole op de server in eigen hand gehouden. Het uitgifteproces van clientcertificaten moet zorgvuldig worden ingericht en worden bewaakt. Op de website kunnen gebruikers inloggen met een persoonlijke gebruikersnaam en wachtwoord om te bekijken wanneer ze toegang hebben gekregen tot een toegangspoort. De autorisatie op de website wordt afgehandeld door de CanCan library voor Ruby on Rails. Deze library maakt het mogelijk om gebruikers toegang te geven en te ontzeggen tot bepaalde onderdelen van de website.
Alle toegangsrechten worden beheerd in één file op de server en staan niet gedupliceerd door de hele code. Common Criteria helpt om vroeg in het ontwikkelproces na te denken over de beveiligingsrisico’s en dit te vertalen naar de juiste set aan security requirements. TASS ontwikkelt veilige software. Vooral bij de systemen die nu steeds vaker aan het internet worden gekoppeld is dit van groot belang. TASS streeft daarom naar veilige software voor alle systemen. Hoe eerder u nadenkt over beveiliging, hoe goedkoper u uiteindelijk uit bent. Hiermee wordt voorkomen dat uw bedrijf op een negatieve wijze in de media komt en bespaart u uiteindelijk veel geld. Veilige software voor alle systemen. Is dat ook uw ambitie? Join our future!
TASS technology solutions T +31 (0)40 250 32 00 Larixplein 6 E
[email protected] 5616 VB Eindhoven W www.tass.nl/www.tass.be
