Copy
Bergler Software Solutions introduceert haar maandelijks ‘Developers-blog’, bestemd voor IT-managers, leidinggevenden, software-ontwikkelaars etc. Bekijk onze meest recente publicaties!

Software Security - Risico Analyse




In dit artikel beschrijf ik de stappen die nodig zijn voor het maken van een (eenvoudige) risico analyse.
De eerste stap, maar ook een van de belangrijkste, voor de beveiliging van je informatiesystemen is vergaren van kennis. Je moet weten hoe je eigen systemen, maar ook de ingekochte systemen, gebruik maken van methoden en technieken. Met systemen bedoel ik dan niet alleen de software, maar zeker ook de hardware, firmware, protocollen enzovoorts. In principe kan elke onderdeel van een informatiesysteem kwetsbaar zijn, en daardoor ook gevoelig voor misbruik; denk bij elk onderdeel ook aan communicatiemogelijkheden als USB, Bluetooth, FTP, enzovoorts.

Ook onderdelen die niet van het bedrijf zijn, maar binnen het bedrijf of voor bedrijfsinformatie gebruikt kunnen worden, kunnen een onveilige situatie veroorzaken. Denk daarbij aan een smartphone of notebook die ook voor bedrijfsmail gebruikt. In het totaalplaatje van je systemen moet je dan ook alle mogelijke onderdelen meenemen.

» Lees het hele artikel

RyuJIT


Tegenwoordig draait alles op 64-bit.
Terwijl dat niet altijd beter of sneller hoeft te zijn ten opzichte van 32 bit
Een heleboel programma’s werken beter op 32-bit om allerlei redenen.
Een goed voorbeeld is de 64-bit JIT compiler van Visual Studio. Die compiler is heel goed in het sneller maken van je code/programma maar is van zichzelf niet snel.

Uh … 64-bits?
Het lijkt af en toe wel alsof de 32-bit x86 computer altijd heeft bestaan. Qua architectuur is het fantastisch, maar het heeft 1 probleem: een 32-bit pointer die maar 4GB RAM aankan. 64-bit computers, met grotere – bredere – pointers kunnen bijna ongelimiteerde hoeveelheden aan. Omdat RAM oorspronkelijk duur was, werden eigenlijk alleen servers uitgerust met 64-bits architectuur. Tegenwoordig komt bijna alles met een 64-bits architectuur. Zelfs smartphones en dat terwijl die vaak nog minder als een 1 GB RAM hebben.

De oorspronkelijke 64-bit JIT was ontworpen om efficiënte code te produceren gedurende de lange levensloop van een server proces. Dit in tegenstelling tot de x86- JIT die ontworpen is om snel code te produceren zodat programma’s sneller starten. De tijd nemen om efficiënt te compileren is een logische keuze als het om server code gaat, maar “server code” is tegenwoordig ook een webapp die snel moet starten. De huidige .NET 64-bit compiler is niet altijd het snelst als het gaat om compileren wat weer betekent dat je afhankelijk bent van technologieën als NGEN of background JIT om snelle opstart mogelijk te maken

De redding
RyuJIT. Dit is een JIT compiler (gemaakt door het .NET Code Generation team) die twee keer zo snel is en dat betekent dat apps 30% sneller opstarten. (De tijd die nodig is voor de JIT Compiler is maar 1 component van de opstart tijd, dus je app start niet twee keer zo snel. Daarnaast wordt er nog steeds die efficiënte server code geproduceerd).


» Lees het hele artikel
"Ik geloof dat een mix van architectuur- en theoretische kennis tezamen met een praktische benadering de beste manier is om softwareontwikkeling tot een succes te maken. Voor het team van projectleads ben ik vooral bezig met mijn passie: softwaresecurity. Hiervoor zoek ik vooral naar mogelijkheden voor het inpassen van security in alle lagen van de software.

Jos Raijmakers, Project Lead Bergler Software Solutions
Mijn huidige opdrachtgever, een leverancier van productiesystemen voor de procesindustrie, is bezig om de bestaande software-systemen te moderniseren. Op dit moment worden er nog een aantal VB6 applicaties gebruikt, maar men wil deze zo spoedig mogelijk overzetten naar een dotNet / C# omgeving.
 
Mijn taak hierbij bestaat uit een aantal stappen. De eerste stap is het inventariseren van de mogelijkheden om de VB6 programmatuur automatisch te kunnen converteren naar dotNet (eventueel VB.Net, voorkeur C#). De tweede stap is het in kaart brengen van de gebruikte (verouderde) technieken en componenten-pakketten (en het zoeken naar alternatieven hiervoor). De derde stap is het aanleveren van een lijst van alle projecten, zodat het team kan aangeven welke projecten al dan niet geconverteerd moeten worden.  De vierde stap is het uitvoeren van enkele proefconversies. Zo kan er bepaald worden wat de kwaliteit is van de automatisch conversie en kan er een inschatting worden gemaakt van de benodigde tijd voor een handmatige correctie.
  
Naast het conversietraject is het ook belangrijk om het VB6 team voor te bereiden op de nieuwe Visual Studio omgeving, het gebruik van Team Foundation Server en het leren van dotNet en de C# taal. Deze vijfde stap bestond dan ook uit het geven van enkele cursussen en het begeleiden van het team.
 
Inmiddels is de definitieve automatische conversie uitgevoerd en is de zesde stap gestart: de handmatige correctie van de automatisch conversie. De verwachting is dat binnenkort de volgende stap gezet kan worden: het integraal testen va de geconverteerde applicaties.
Copyright © 2015 Bergler Nederland BV, Alle rechten voorbehouden.


Klik hier om u af te melden voor onze nieuwsbrief