Alle artikelen in categorie "Artikelen"

Het Security Development Lifecycle process, fase nul.

nov 13, 2011   //   door Olav   //   ALM  //  Geen reacties

In het vorige artikel ben ik ingegaan op het Security Development Lifecycle proces en waarom je dit proces wilt gebruiken in het ontwikkelen van nieuwe software. In dit artikel ga ik in op de eerste van dertien fases die gezamenlijk het SDL proces vormen.

Het SDL proces bestaat uit dertien fases die we tellen vanaf fase nul. Hierdoor heet de laatste fase niet fase 13, maar fase 12 waarmee we het ongeluksgetal 13 vermeiden. Dat is wel zo lekker voor het succes van een SDL implementatie.
Daarnaast is fase nul ook een fase die niet zozeer van toepassing is op een project, maar een fase waar alle lagen van de organisatie aan zal moeten geloven, of ze nu in projecten zitten of niet.

Fase 0. Education and Awareness

Kennis en bewustwording over veilige software vormen de basis van veilige software zoals dat ook geldt voor zoveel andere zaken. Helaas is er bij de ‘software ontwikkelaars’ van vandaag de dag weinig kennis aanwezig over veilige software en zijn er ook weinig ‘security professionals’ die de nodige kennis en ervaring bezitten. Iets wat op korte termijn ook niet opgelost gaat worden.

Veel software ontwikkelaars gebruiken ontwikkelstandaarden zoals RUP en Agile die geen directe focus hebben op veiligheid van de software. Om dit te veranderen zou de software industrie een verplicht semester moeten hebben voor alle professionals gericht op veiligheid van software en privacy. Of minimaal alle professionals betrokken bij the ontwerpen, ontwikkelen, testen en documenteren bewust maken van de onderwerpen veiligheid van software en privacy.
Dit kan door bijvoorbeeld de DVD’s en CD’s die vaak bij boeken over veiligheid van software wordt geleverd te verspreiden onder de professionals.

Maar het moet in ieder geval een vast onderdeel worden van de organisatie, gedragen door alle lagen van de organisatie, waarbij iedereen jaarlijks zijn kennis opvijzelt over veiligheid en privacy!

Daar heeft iedereen voor nu wel voldoende werk aan dus later meer over de andere SDL fases.

Een duoblog met Kees Romkes. Waar raken wij elkaar?

okt 5, 2011   //   door Olav   //   Algemeen, Artikelen  //  Geen reacties

Een duoblog met Kees Romkes (@KeesRomkes) over social en technology. Waar raken wij elkaar?

@KeesRomkes: Ik ben maar zo brutaal om deze Q&A te starten. Ik ken Olav inmiddels al ruim 12 jaar als ik me niet vergis, begonnen in 1999 samen op het MBO met de opleiding kantoorautomatisering. Waar hij nog nauwelijks een computer had aangeraakt, was ik al redelijk doorwintert. Van complete 0 naar waar hij nu staat is wat dat betreft ook nogal een verhaal op zich. Voor mij is Olav in 140 tekens:

“(digitale) knuffelbeer, whiteboard expert, systematisch doordenker, wannabe-klusser, cloud guru, microsofty”

en dan heb ik nog tekens over. Olav, jij bent aan de beurt ;-)

@Okwakman: Dank je Kees. Nog een paar maanden en we hebben ons eerste jubileum ;-) Na de MBO opleiding hebben we ieder ons eigen toekomst pad gekozen waar jij je vooral richtte op de creatieve kant van technologie en ik volledig opging in de business kant van de technologie. Paden die elkaar meermaals kruisen wanneer creativiteit en techniek samensmelten in nieuwe ideeën. Daar ligt de kracht en het succes van onze samenwerkingen!

Kees is voor mij in iets minder dan 140 tekens:

“Enthousiaste sociale creatieveling, gadget-freak, techneut, Steve Romkes Jobs, digitaal medium en levensgenieter”

Sinds kort ben ik werkzaam bij Tresoar. Het Fries cultureel en historisch centrum in Leeuwarden als teamleider ICT met een grote uitdaging. Aansluiting zoeken bij de digitale wereld.

Het is hier waar ik weer werd geconfronteerd met de frustratie die mij al tijden bezig houdt. De presentatie van informatie. Feitelijk zijn we qua presentatie van informatie nog geen stap verder dan de uitvinding van de boekdrukkunst in 1501 (Europees gezien dan).
We proppen nog steeds informatie op het scherm met als uitgangspunt dat we het kunnen drukken op een fysiek medium.
Aan de andere kant echter ontwikkelen de schermen zich steeds meer in de breedte waarmee het lastiger wordt om informatie te presenteren die opgemaakt is richting de hoogte. Neem nu een document met de opmaak voor A4 en presenteer dat op elke willekeurige full HD scherm. Maar toch wanneer ik welk office pakket dan ook open, de oriëntatie van de informatie is nooit in de breedte.
En dan vindt men het raar dat e-books niet zo’n overweldigend succes zijn?

Ook moet ik constateren dat we in de huidige digitale wereld veel meer informatie tot onze beschikking hebben en dat dit ook de manier van leren veranderd bij iedereen die de digitale wereld omarmt.
Waar men vroeger een boek met informatie doorworstelde om tot antwoorden te komen, raadplegen we nu alleen nog maar die informatie die antwoorden geeft op onze vragen. We leren in dat op zich minder, maar raadplegen daar in tegen veel meer. En wanneer de informatie is gevonden, vergeten we vaak de informatie. We onthouden alleen nog maar de locatie waar de informatie te vinden is.
En met een groeiende bron aan informatie wordt dat steeds lastiger. Steeds vaker en vaker zijn we veel tijd kwijt met het filteren van deze informatie, want zeg nou zelf, hoe vaak geven de gesponsorde links van Google jou het antwoord?

Ik ben daar klaar mee, en jij gelukkig ook. Tijd om het te veranderen! Maar hoe?
Door te onderzoeken welke informatie wanneer waarde heeft. Welke factoren van een event invloed hebben op de type informatie die ik wil raadplegen.

Dat alles begint bij de definitie van een event, iets waar je in je vorige artikel al op bent ingegaan. Een visie waar we al veel over hebben gesproken en die is vormgegeven door onze kennis en expertises.

Olav verwoord het erg gaaf en zowel op sociaal, als technisch vlak, komen we daar samen wat zaken in tegen waar verandering plaats zal moeten vinden. Te beginnen bij de aard van het beestje zelf, de manier waarop we informatie presenteren. Technologie stelt ons al tot zoveel in staat, laten we de volgende stap eens zetten om die technologie te gebruiken om de beschikbare informatie in een nieuwe context te plaatsen, gebaseerd op de definitie van Events. Een hele mond vol, maar wij gaan het doen.

Je eigen internet onderneming in de cloud

mrt 6, 2011   //   door Olav   //   Cloud Computing  //  Geen reacties

Een online onderneming hoeft niet duur te zijn. Noch heb je daar een jarenlange IT studie voor nodig om het voor elkaar te krijgen. Door slim gebruik te maken van veelal gratis of goedkope diensten ben je in staat om je eigen website te maken, een email systeem te gebruiken met je eigen domeinnaam en online (samen)werken aan documenten. En hoewel er meerdere spelers op de markt zijn heeft één bedrijf het perfect voor je geïntegreerd: Google biedt namelijk al deze mogelijkheden geïntegreerd achter één account.

Weten hoe?

Door onderstaande vier stappen te volgen is jouw online onderneming € 7,50 en een paar muisklikken van je verwijderd.

Meer >>

Team Foundation Build

mrt 3, 2011   //   door Olav   //   ALM  //  Geen reacties

Security Development Lifecycle – SDL

dec 31, 2010   //   door Olav   //   ALM  //  2 Reacties

Het Security Development Lifecycle (SDL) is geboren bij Microsoft in 2002 onder de noemer ‘Trustworthy Computing’ als reactie op een groeiende vraag uit de markt om veiligere software. Deze marktvraag roept meteen een andere vraag op:

“Waarom zou ik mij druk maken om veiligere software?”

Het antwoord op die vraag ik simpel: De wereld van vandaag is meer met elkaar verbonden dan ooit tevoren en zal zonder twijfel meer verbonden raken in de toekomst. Met deze grote mate van verbondenheid is er een grote dreiging bijgekomen voor software gebruikers. Niet langer hebben we te maken met het voor de ‘fun’ en ‘fame’ kraken van websites en applicaties, maar hebben we te maken met ‘cybercrime’.

Daarnaast is aangetoond dat software die niet afkomstig is van de vier grootste software leveranciers (Microsoft, Apple, Oracle en IBM) het meest gevoelig is voor beveiliging risico’s.

Applicatie beveiliging risico's

Applicatie beveiliging risico's

“Waarom dan SDL?”

Het Microsoft Security Development Lifcycle biedt software ontwikkelaars een ‘veiligheid garantie proces’ wat bestaat uit activiteiten die gecombineerd met het Agile ontwikkel proces geschikt is om te integreren in Microsoft Visual Studio Team System 2010. Want hoewel Agile beveiliging van software meeneemt in de proces beschrijving, ligt de focus binnen het Agile proces op het kostenefficiënt opleveren van software. SDL is dus een mooie aanvulling op het Agile proces.

SDL zorgt ervoor dat er door het hele ontwikkel proces heen nagedacht moet worden over de veiligheid van de software. Door deze focus is het aannemelijk dat beveiligingsrisico’s al in een vroeg stadium geïdentificeerd kunnen worden. Hoe eerder deze riscio’s geïdentificeerd worden hoe goedkoper het is om deze op te lossen. Het National Institute of Standards and Technology heeft zelfs berekend dat fouten oplossen na een oplevering 43% duurder is dan het oplossen van dezelfde fout in de ontwerpfase, aan het begin van een ontwikkelproces.

Voor Microsoft heeft het SDL proces in ieder geval geholpen bij het ontwikkelen en onderhouden van Windows Vista. Uit eigen onderzoek van Microsoft blijkt dat na de implementatie van het SDL proces de beveiligingsrisico’s zijn afgenomen met 45%.

Voordelen SDL Microsoft

De voordelen van SDL voor Microsoft.

Daarnaast is het SDL proces flexibel genoeg om te integreren met elk ander ontwikkel proces. Door het combineren van SDL met een bestaand ontwikkel proces verbeter je de veiligheid van de software zonder dat er een heel nieuw ontwikkelproces geadopteerd moet worden. Het is dus geen proces dat alleen maar te combineren valt met het ALM platform van Microsoft, en het verbeterd de kwaliteit van je software.

Uiteindelijk gaat het om kwaliteit!

Wanneer we het nu hebben over privacy, beveiliging of betrouwbaarheid, uiteindelijk hebben we het over kwaliteit van de software die we ontwikkelen.

Kwaliteit

Kwaliteit

Voor grote software ontwikkel bedrijven is kwaliteit dan ook een onderwerp die niet zomaar genegeerd wordt vanwege de grote hoeveelheid gebruikers die de software van deze bedrijven gebruiken. Alleen al de kosten voor het uitbrengen van kwaliteitsverbeteringen in de vorm van updates is reden genoeg om beveiligingsrisico’s zo vroeg mogelijk te constateren en het SDL proces in overweging te nemen.
Voor In-House software ontwikkelaars ligt het anders, hier biedt het SDL proces ‘alleen’ voordelen op het gebied van beveiliging. Hoewel beveiliging lastig te kwantificeren valt als het om In-House software gaat is biedt SDL een mooie beveiliging bonus boven op betrouwbaarheid en privacy.
Tenslotte hebben we dan nog de kleine software ontwikkel bedrijven. Hier gaat software ontwikkelen vaak via de ‘hacking the code’ methode wat een efficiënte werkwijze is om snel code te produceren maar ook snel defecten. Hier kan het SDL proces als meetinstrument worden toegepast om de kwaliteit van de software te meten.

Kortom, SDL zorgt ervoor dat de kwaliteit van onze software verbeterd. Iets wat iedereen zou moeten aanspreken!

Een goede beheersbare BizTalk infrastructuur

nov 25, 2010   //   door Olav   //   Integratie  //  1 Reactie

Ahold de cloud in!

sep 18, 2010   //   door Olav   //   Cloud Computing  //  Geen reacties

Bron: Official Google Enterprise Blog.

Ahold een internationale detailhandel in levensmiddelen, bekend van onder andere Albert Heijn, Stop & Shop en Giant Food is over gegaan op Google Apps, de cloud diens van Google. Ahold heeft meer dan 2900 winkels over de hele wereld. Volgens Google is Ahold de grootste Google Apps afnemer geworden in de Benelux.

Ahold maakte de beslissing om te verhuizen naar Google Apps om haar wereldwijde werknemers te voorzien van één web-based platform voor communicatie en samenwerking en ter vervanging van bestaande e-Ahold-domeinen en computer systemen in Europa en de VS. Door deze migratie kan Ahold volgens Google miljoenen besparen, onder andere omdat het nu geen omkijken meer heeft naar hardware en onderhoud.

Ahold koos Google Apps voor de 25 GB Gmail-opslag, 10GB plus 500MB per gebruiker voor gedeelde Google Sites-opslag, geïntegreerde Instant Messaging (Google Talk) en een reeks bijkomende functies die communicatie, waaronder video gebaseerde communicatie, automatische vertaling en gedeelde agenda’s vergemakkelijken. Daarnaast ontvangt Ahold 24 uur per dag ondersteuning van Google.

Cloud computing, de basis…

aug 31, 2010   //   door Olav   //   Cloud Computing  //  Geen reacties

ASP, SaaS, PaaS, IaaS, utility computing en virtualisatie zijn zomaar een paar diensten en technieken die door veel bedrijven met ‘cloud computing’ in verband wordt gebracht. Maar wat betekend ‘cloud computing’ nu eigenlijk? Om die vraag te beantwoorden beginnen we bij het begin, cloud…

Het gebeurd daar ergens, in de wolken…

De naam cloud zal voor velen net zo onbegrijpelijk klinken als Web 2.0. Dat komt doordat cloud net als Web 2.0 een verzamelnaam is. Het woord cloud is een aanduiding voor het internet of een intranet en kent zijn oorsprong bij het uitvinden van de ‘packet switching’ technologie waar het internet gebruik van maakt.
In het kort komt het er op neer dat door de packet switching technologie de route van A naar B niet meer te bepalen is.
De onderstaande illustratie laat heel mooi zien wat de packet switching technologie inhoud en hoe het woord cloud hierin past.

Packet Switching

Figuur 1: Packet switching via de cloud

In de afbeelding bevat de cloud allemaal knooppunten die het internet verkeer routeren totdat het verkeer aankomt bij zijn bestemming. Elk knooppunt bepaalt het volgende stuk van de route door te kijken naar de meest efficiënte route. Die hoeft niet per definitie altijd dezelfde route te zijn, zo kan een storing in een knooppunt er bijvoorbeeld voor zorgen dat al het internet verkeer niet meer via dat knooppunt gerouteerd wordt, of kan de belasting van een knooppunt voor vertraging zorgen. Vandaar het woord cloud, als aanduiding dat het verkeer via het internet/intranet gerouteerd wordt en het niet te bepalen is of het verkeer nu via Nederland, IJsland of Zuid Afrika gerouteerd wordt.

Maar de cloud houdt meer in dan alleen knooppunten. Wanneer je bijvoorbeeld een zoekopdracht invoert op Google zal de zoekopdracht via de knooppunten uitkomen op een willekeurige server van Google, die vervolgens voor je gaat zoeken en de zoekresultaten via de knooppunten terugstuurt. In dit voorbeeld behoort de willekeurige server van Google ook tot de cloud omdat je niet kunt zeggen waar deze server zich fysiek bevind.

Dus nu weet je hoe het zit met de ‘cloud’, maar hoe zit het dan met ‘computing’?

Computing

Computing, vrij vertaald informatica, wordt vaak gedefinieerd als de activiteit van het gebruik en de verbetering van de computertechnologie, computer software en computer hardware. In cloud computing ligt de nadruk op het gebruik van computertechnologie, soft- en hardware.

Cloud Computing

Cloud computing is voor het eerst gedefinieerd door Ramnath K. Chellappa in 1997. Hij definieert cloud computing als volgt: “a computing paradigm where the boundaries of computing will be determined by economic rationale rather than technical limits.” De vertaling van dit moment is volgens mij: “Computertechnologie, computer software en computer hardware wat aangeboden wordt via het internet of intranet via een kostenmodel gebaseerd op basis van het gebruik van in plaats van het bezit.

Dus echt overal en altijd toegang tot de cloud computing diensten die je afneemt. Lage opstartkosten omdat je de hardware en software niet hoeft te kopen. In tegenstelling tot het leasen van hard- en software worden de kosten van de cloud computing dienst afgezet naar het gebruik en zijn de aanbieders, die verstand hebben van hard- en software, verantwoordelijk voor het onderhoud hiervan. Kortom een concept waar je niet omheen kan!

Ik hoop dat je met dit artikel een helder beeld kunt vormen van cloud computing en waarom dit voor jou een geschikte oplossing kan zijn. In het volgende artikel leg ik uit hoe de techniek zich in de laatste jaren heeft ontwikkeld tot cloud computing, vertel ik hoe je zelf je applicaties naar ‘de cloud’ brengt en ga ik in op de risico’s die het leveren en het gebruik van cloud computing met zich meebrengt.
Denk je serieus na over een migratie naar ‘de cloud’ en kun je hier wat adviezen in gebruiken? Neem dan gerust contact met mij op.

Test Driven Development met Visual Studio Team System 2010. Deel 2.

aug 23, 2010   //   door Olav   //   ALM  //  Geen reacties

In het vorige artikel ben ik ingegaan op de basis principes van Test Driven Development en heb ik met een voorbeeld laten zien hoe je dit doet met Visual Studio 2010. Nu is het tijd voor het vervolg…

Wanneer er wordt gesproken over het toepassen van een ontwikkel methodieken in het algemeen zijn er meestal ook meerdere personen betrokken bij de ontwikkeling van het nieuwe product.
En in dit geval hebben we voor het project TddDemo een tester aangenomen om test data te ontwikkelen. Om het verhaal geloofwaardig te maken claimt deze tester geen verstand van techniek te hebben, en wanneer er op zijn PC geen Excel is geïnstalleerd, is deze tester reddeloos verloren.

Gelukkig maar dat we test data kunnen inlezen vanuit een csv, xml of database bestand.

Meer >>

Test Driven Development met Visual Studio Team System 2010

jul 15, 2010   //   door Olav   //   ALM  //  1 Reactie

Wat is Test Driven Development?

Test Driven Development is een ‘relatief nieuwe‘ benadering van software ontwikkeling die is gebaseerd op de herhaling van een zeer korte cyclus van ontwikkeling. De cyclus bestaat uit vijf stappen:

Als eerste stap definieert de ontwikkelaar een geautomatiseerde testcase die de nieuwe verbetering of functie beschrijft en test. De test moet per definitie falen omdat de test eerder wordt geschreven dan de code, om dit te controleren is stap twee van de cyclus het vaststellen dat de test inderdaad faalt.
Daarna produceert de ontwikkelaar code om de test succesvol te laten verlopen en om te controleren dat de code goed is geschreven volgt stap vier, het opnieuw uitvoeren van de test. Als laatste optimaliseert de ontwikkelaar de code naar geaccepteerde standaarden (refactoren).

Door gebruik te maken van Test Driven Development zou het aantal fouten in de software tot een minimum beperkt moeten worden wat weer een gunstig effect heeft op de kostprijs. Voorkomen is nu eenmaal goedkoper dan genezen. Daarnaast zal er over het algemeen genomen niet meer code geschreven worden dan nodig is om de test succesvol te doorlopen en daarmee te voldoen aan de functionaliteit die gevraagd wordt door de klant.

Er zijn ook nadelen aan Test Driven Development, zo is het moeilijk om te implementeren wanneer er volledige functionele tests nodig zijn om vast te stellen of de code voldoet aan de eisen en zijn de tests zelf een onderdeel van de beheer overhead van een project.

Om Test Driven Development te implementeren is er een unit-test framework beschikbaar in Visual Studio 2010. Lees verder om uit te vinden hoe je Test Driven Development kun implementeren…

Meer >>

Pagina's:12»