Ruim een derde van mkb loopt risico door onbeveiligde printers

Ruim een derde (38 procent) van de mkb’s in de Benelux stelt zichzelf bloot aan een groot datalek omdat ze hun printers en multifunctionele printers (MFP’s) niet voldoende beveiligen. Dat blijkt uit nieuw onderzoek van Sharp.

De belangrijkste conclusie uit het onderzoek van Sharp is, dat kantoormedewerkers in de Benelux zich anno 2019 niet bewust zijn van de potentiële beveiligingsrisico’s die printers en MFP’s met zich meebrengen. Zo ziet 65 procent van de respondenten deze apparaten niet als een risico voor de IT-omgeving. Ook het achterlaten van geprinte documenten op het toestel wordt niet als risicovol gezien: slechts een vijfde (21 procent) van de kantoormedewerkers beseft dat dat niet slim is.

Nieuws

Hoewel printer-hacks steeds vaker het nieuws halen - zo wist een fan van de Zweedse YouTuber PewDePie zonder enig probleem 50.000 printers te hacken - is maar dertig procent van de respondenten op de hoogte van het feit dat printers überhaupt gehackt kunnen worden. Zij zagen daarnaast niet in dat een onbeveiligde printer een risico vormt voor hun bedrijf. Als reactie op de onderzoeksresultaten creëerde Sharp een gids voor een betere printerbeveiliging voor mkb’s, ontwikkeld in samenwerking met ethische hacker Jens Müller. De gids ‘Eenvoudige printerbeveiliging voor mkb’s’ is gratis te downloaden op www.sharp.be/printerbeveiliging en bevat onder meer eenvoudige tips voor medewerkers die verantwoordelijk zijn voor de kantoortechnologie.

Risico

Müller over het risico van printen: “Printers vind je overal. Elk bedrijf heeft er een, en moderne printers zijn meestal verbonden met het bedrijfsnetwerk. Dat houdt in dat ze, wanneer ze niet goed beveiligd zijn, een makkelijk doelwit zijn voor hackers. Printers en MFP’s bieden namelijk niet alleen toegang tot gevoelige geprinte, gescande of gefaxte documenten, maar ook tot de rest van het bedrijfsnetwerk. Hackers hoeven maar één kwetsbare plek te vinden en ze zijn binnen. Vervolgens kunnen ze grote schade aanrichten.” Voor kleinere bedrijven vormt de beveiliging van de printer mogelijk een nog groter probleem: bedrijven met minder dan 50 medewerkers beschikken minder vaak over goede beveiligingsfuncties. Zo laat 49 procent van deze bedrijven iedereen de printer vrij gebruiken, in tegenstelling tot 22 procent van de grotere organisaties (151-250 medewerkers). Afdelingen die veel omgaan met gevoelige of vertrouwelijke informatie, zoals HR of de juridische afdeling, beschikken bovendien relatief vaak over minder basisbeveiligingsfuncties: in 38 procent van de gevallen kan iedereen de apparaten vrij gebruiken. Gezien de aard van de documenten waar deze afdelingen mee te maken hebben, riskeren hun organisaties - naast dataverlies - ook een fikse boete als er daadwerkelijk een datalek ontstaat.

Marco van Vliet, Product Marketing Manager Document Solutions bij Sharp: “Een datalek kan een grote negatieve impact hebben op elk bedrijf, ongeacht de omvang. Zoals ons onderzoek laat zien, beschikken kleinere bedrijven vaak over minder middelen om de risico’s op een datalek te verkleinen. Daarom is het zo belangrijk dat medewerkers goed worden ingelicht over de risico’s. Wat veel bedrijven daarnaast niet weten, is dat ze met enkele simpele functies of software kunnen bijdragen aan het voorkomen van een datalek.”

Van de redactie

Pleidooi voor meer aandacht voor de impact van software op energiegebruik

Green IT is niet mijn probleem - of toch wel?

Als het gaat om het verduurzamen van ICT wordt tot nu toe vooral gekeken naar datacenters en IT-hardware. Maar al te gemakkelijk wordt vergeten dat ook de programmatuur die gebruik maakt van deze hardware-omgevingen een grote impact heeft op energiegebruik en - bijvoorbeeld - uitstoot van CO2. Het wordt tijd dat ook softwareontwikkelaars en IT-architecten hun verantwoordelijkheid nemen als het om Green IT gaat, meent Marcel den Hartog.

Wat iemand ook van de huidige discussies over CO2-uitstoot, stikstofproblemen, energietransitie of welke andere milieudiscussies dan ook mag vinden, als IT-industrie moeten we ernstig rekening houden met deze sentimenten. Niet op cijfers gebaseerde of oude uitspraken als ‘één Google search kost net zo veel als een gloeilamp die 17 seconden brandt’ of ‘één Google search kost net zo veel als een autorit van 65 meter’, worden makkelijk gedaan en datacenters krijgen al snel het stempel van energievreters en CO2-uitstoters. Met 77,681 Google searches en 79,917GB aan internet-verkeer per seconde kun je op die manier alles een dramatische draai geven. Zet er een plaatje naast van een enorm datacenter met veel flikkerende lampjes, enkele tienduizenden servers en heel veel netwerkapparatuur om alles met de buitenwereld te verbinden en iedereen begrijpt dat het niet lang meer gaat duren voordat wij - als IT-industrie - dezelfde stempels opgedrukt krijgen als raffinaderijen, varkensboeren, luchthavens en dieselmotoren.

Door een dreigend tekort aan capaciteit van het elektriciteitsnetwerk, zijn de meeste datacenters - met name de bedrijven in de Randstad - zich hiervan bewust en zien we dat er aan allerlei creatieve oplossingen gewerkt wordt om te voorkomen dat het energieverbruik uit de hand gaat lopen. Maar tot mijn verbazing gaat het hier vooral over hardware-oplossingen en blijft de rol van de software - en daarmee de rol van de software architect, de ontwikkelaar/programmeur, de database administrator en dergelijke - onderbelicht.

Al jaren zien we dat de capaciteit van de processoren, de snelheid van solid state disks (SSD) en de hoeveelheid geheugen in onze laptops en werkstations enorm toeneemt. Verrassend genoeg starten programma’s en processen nog steeds net zo snel op als drie, vijf of zeven jaar geleden, afgezien van de toename in snelheid die we van SSD’s mogen verwachten. Tegelijkertijd zien we de omvang van de applicaties en apps die we gebruiken enorm toenemen. Voorbeeld: op mijn eigen werkstation staat een PDF Reader die (volgens opgave) 486MB in beslag neemt. Naast een alternatief van 2MB. Ik zie ook een video editor van 759MB en een alternatief hiervoor van 198MB. Natuurlijk is dit commerciële software op een privé-werkstation, maar mijn ervaring met in-house geschreven of gekochte applicaties voor professioneel gebruik is niet anders. Ik zie een aantal belangrijke oorzaken:

Libraries. De simpelste programmatuur wordt, vaak door het opnemen van allerlei libraries (je weet immers maar nooit waar die goed voor kunnen zijn…), al honderden megabytes groot. Megabytes die gecompileerd, geladen en getest moeten worden. MB’s die van development naar testafdeling naar acceptatie naar productie verscheept moeten worden. Megabytes die in het geheugen geladen worden van servers en werkstations en megabytes die door de netwerkkabels gepompt moeten worden. Natuurlijk wordt er ‘gecached’ en gevirtualiseerd, maar het blijven megabytes en gigabytes. En met honderden gebruikers worden gigabytes uiteindelijk gewoon terabytes… Agile Development. Door de toenemende druk om iedere dag, iedere week of iedere twee weken een nieuwe versie van een softwareprogramma te lanceren, moeten er concessies gedaan worden. En tuning hoort daar helaas bij. Agile gaat mijns inziens voorbij aan het feit dat een grote applicatie zich bijna gedraagt als een organisme op het moment dat hij in productie genomen wordt. Plotseling zijn er zoveel randverschijnselen die het gedrag van de applicatie beïnvloeden, dat bottlenecks die eerst niet zichtbaar waren plotseling een enorme impact hebben. Databases met miljoenen rows, duizenden gebruikers, netwerk latency, applicaties die via API’s met onze applicatie communiceren - allemaal hebben ze impact op het gedrag van onze

{‘De simpelste programmatuur wordt vaak door het opnemen van allerlei libraries al honderden megabytes groot. Megabytes die gecompileerd, geladen en getest moeten worden’

applicatie. Maar tegen de tijd dat we de twee grootste problemen hebben opgelost en toe zijn aan de tien kleinere die ook zorgen voor meer geheugengebruik of een toename in dataverkeer, is er weer een nieuwe versie met nieuwe problemen. We krijgen zelden of nooit de kans om het ‘organisme’ als geheel een tijdje te tunen en te stroomlijnen. De ‘hardware jongens’ lossen het wel op. Servertje erbij, beetje geheugen en ‘gaan met die banaan’. Het wachten door slechte performance blijft echter bestaan, de gebruikers wachten alleen maar een beetje sneller. Logbestanden, de ‘verzekeringspolis’ van veel beheerders. Dankzij logbestanden kunnen we na een database crash alles veilig terugzetten. Dankzij log-bestanden weten we welke superuser de back-up heeft gestopt omdat hij iets eerder naar huis moest en welke secretaresse de user-id/password combinatie van haar manager gebruikt om facturen te boeken én te betalen. Maar hoeveel logbestanden hebben we eigenlijk? En wat gebruiken we daar nu eigenlijk van? Zijn die 200Gb grote logbestanden die per uur gegenereerd worden nu echt nodig? Of kunnen we dit misschien halveren? En ik hoor mensen denken: ‘200Gb?! No way!’. Geloof me, het is in 75% van de bedrijven veel meer dan dat (zie kader).

De oplossing(en)

Ik denk dat iedereen zich in bovenstaande herkent. Maar welke stappen moeten we nemen om ons steentje bij te dragen? Allereerst zullen de enterprise IT-architecten zich moeten verdiepen in de materie. Hoe kunnen we de business blijven ondersteunen en hoe kunnen we dit verbeteren zonder dat we volgend jaar wéér extra megawatts moeten reserveren bij onze provider? Moet er een extra stap in ons agile-proces gebouwd worden om stabielere, efficiëntere en snellere releases te bouwen? Welke logbestanden zijn er nou echt nodig? Hebben we tools nodig om baselines te zetten en de performance te meten? En als we die tools al hebben, worden die dan ook echt gebruikt? Soms hoor ik architecten met trots zeggen dat zij geen technische achtergrond hebben, maar dit ontslaat hen er niet van om over deze technische zaken na te denken. ‘Het milieu’ staat bij veel bedrijven hoog op de agenda en er is geen enkele reden waarom IT (en dus de architecten) daar géén belangrijke rol in moet spelen.

Maar ook iedere programmeur, DBA en beheerder zal zich achter haar of zijn oren moeten krabben en zich realiseren dat een efficiënt algoritme, een slim stukje code of het aan- en uitzetten van ‘energy savings’ op de servers al snel net zo veel (milieu-)effect heeft als fietsen naar kantoor in plaats van met de auto of het openbaar vervoer.

Voorbeeld uit de praktijk

Voor de sceptici onder ons een klein voorbeeldje (uit de praktijk). Een inefficiënte JAVA SQL call naar een database om via de webpagina een lijst te tonen, duurt ongeveer 0,4 seconden. Dit is 2x langer dan een geoptimaliseerd SQL statement (0,2 sec). Naarmate de database groeit loopt dit iedere week op met ongeveer 0,01 seconde, terwijl het geoptimaliseerde SQL statement deze extra 0,01 seconde pas na 4 weken laat zien. Na 12 weken is de wachttijd 0,52

Over de grootte van logbestanden

Logbestanden kunnen zeer groot zijn. Neem dit voorbeeld dat overigens voor vrijwel alle grote enterprise software-omgevingen opgaat:

SAP HANA Log files:

Examples: - 128 GB system => Sizeredolog = 64 GB - 256 GB system => Sizeredolog = 128 GB - 512 GB system => Sizeredolog = 256 GB - 1 TB system => Sizeredolog(min) = 512 GB - 2 TB system => Sizeredolog(min) = 512 GB - 4 TB system => Sizeredolog(min) = 512 GB

Note: For systems with more than 512 GB in-memory database size, the formula above represents a minimum value. As of today, based on the experience made with productive SAP-internal SAP HANA installations, this value is considered sufficient for each SAP HANA use case. Nevertheless, as described above, as the amount of data stored in the log volume depends on the workload processed, there may be situations where this value is not sufficient for log volume sizing.

Dit is de grootte van het logbestand voor iedere ‘savepoint’. SAP raadt iedere 5 minuten een savepoint aan.

seconden of (geoptimaliseerd) 0,23 seconden. Iedereen die wel eens SQL statements heeft geanalyseerd, weet dat dit absoluut geen overdreven voorbeeld is. Vermenigvuldig dit nu eens met 100 requests per minuut en we praten meteen al over serieuze getallen. Als laatste moeten we natuurlijk gewoon een SLA (service level agreement) afspreken met onze providers. Als we een nieuwe versie uitrollen die aanzienlijk minder efficiënt (of juist efficiënter) is, dan moeten we ook daar de financiële na- en voordelen van zien. En waarom daar geen bonus van maken voor het team dat de grootste sprongen heeft gemaakt?

Bewustwording

Het belangrijkste is, dat we ons bewust worden van de rol die we spelen. Hoe goed ben je bezig als je alle gloeilampen thuis vervangt door energiezuinige led-verlichting en je tegelijkertijd een nieuwe versie van je app of applicatie aanbiedt die op jaarbasis een veelvoud aan extra energie verbruikt? Zelfs de app op je mobiele telefoon moet geen gedrocht worden waardoor gebruikers (jij dus) een kwartier of half uur eerder aan de oplader moeten. Toch?

Marcel den Hartog werkte dertig jaar voor een grote aanbieder van enterprise software