Yep, huur een bedrijf in die het doet voor je. Anders ben je een slager die zijn eigen vlees keurt.

FOX IT medewerkers kunnen dat toch zelf? Of ben je van Madison Ghurka?

Niet mee eens. Begin met een eigen check zodat je weet waar een externe auditor het over heeft en in hoeverre deze serieus moet worden genomen (c.q. er alleen op uit is om jouw bedrijf grote sommen geld uit de zak te kloppen). Voorwaarde is dat je je wel eerst in de materie verdiept. Begin bijv. hier: http://www.sans.org/critical-security-controls/.

Als je zelf een beeld hebt, en (in overleg met leidinggevenden) normen hebt opgesteld waar je eigenlijk aan zou willen voldoen, zoek dan een goede auditor. Dat valt niet mee zoals Predjuh in zijn reacties hier aangeeft: http://www.security.nl/artikel/38862/1/Cursus_IB_volgens_ISO27kNEN7510.html.
Succes!

Het probleem met het zelf checken is dat je eigenlijk alleen dingen controleert die je toch al wist, de alom bekende tunnelvisie. Een derde partij zal dat niet doen en dus beter testen.

Uiteraard kies je natuurlijk niet de eerste de beste hit van google om die opdracht uit te voeren. Je gaat, zoals je dat ook met andere zaken doet, offertes aanvragen bij bedrijven die zich al hebben bewezen op dit gebied.

Je zelf controleren is een prima eerste controle:
- Maak eerst een baseline. Wat zou er in een ideaal situatie allemaal geregeld moeten zijn. Zowel wat betreft de techniek (een technische security baseline), als op het gebied van afspraken (SLA's, etc) en je kunt zelfs nog kijken naar de mate van security bewustzijn van de medewerkers. Maak alles meetbaar, controleerbaar.
- Controleer deze baseline vervolgens tegen de werkelijke situatie. En dan wet je wat je mist.
Natuurlijk is het altijd prettig een externe partij in te huren, die heeft net weer een iets andere invalshoek en je ziet gegarandeerd zaken over het hoofd.

Afgezien van de management support die je nodig hebt voor vervolgacties, alsmede duidelijke kaders waartegen je moet toetsen, is een eerste handleiding de lijst in de PDF file http://www.dsd.gov.au/publications/Top_35_Mitigations.pdf. Op die manier kun je vrij vlug in kaart brengen hoe de beveiliging op de belangrijkste gebieden is geregeld. De vraag is alleen wat daarna komt. Belandt je verslag in het bekende ronde dossier, is er tijd en geld om de door jou geconstateerde tekortkomingen aan te passen en permanent op te lossen, ga je op eigen houtje maar wat gaten dichten zonder dat er procedures worden opgesteld die er zorg voor dragen dat anderen het van je overnemen als je op vakantie bent of het bedrijf hebt verlaten, is er voldoende kennis aanwezig om deze zaken op te pakken of zijn er applicatie- of systeembeheerders die koste wat kost hun eigen toko gaan verdedigen "doordat we het altijd zo hebben gedaan" etc.

Het vinden van de zaken is vaak geen probleem, het vervolg is des te interessanter en vereist naast IT kennis ook de nodige politieke sensititivteit en commitment van alle belanghebbenden.

Succes.

Ik zeg ook niet dat je het helemaal niet moet doen, ik zeg alleen dat het beter is om het door een derde partij te laten doen.

Om dezelfde reden dat je een programmeur ook niet zijn eigen software moet laten testen.

@SirDice :

"Het probleem met het zelf checken is dat je eigenlijk alleen dingen controleert die je toch al wist, de alom bekende tunnelvisie."

Het uitvoeren van vulnerability scans, en oplossen van de gevonden problemen, heeft natuurlijk wel degelijk nut. Al is het altijd handig op vervolgens een externe audit/pentest uit te laten voeren.

Kijk eens naar het programma nessus eventueel in combinatie met metasploit
Nessus verschat je een mooi rapport in diverse formaten over vulnerabilities.

"De enige reden om software door een ander te laten testen is als je met de resultaten naar buiten wil treden."

Nee hoor, het is ook handig om een second opinion te hebben indien je niet naar buiten wilt treden. Penetration test en audit rapporten worden meestal door buitenstaanders gemaakt, en worden zelden of nooit openbaar gemaakt.

Het heeft helemaal niets met kennisniveaus te maken. Het heeft te maken met het feit dat je, onbewust, alleen in een bepaalde richting zoekt. Iemand die de software (of jouw netwerk) niet kent zal alle opties open houden en dus gewoon degelijker testen. Bovendien is er een groot verschil tussen functioneel testen en technisch testen.

Als je zelf een keer wat gemaakt hebt zul je vast bekend zijn met het fenomeen "blind staren". Vervolgens komt er een collega langs die jouw code nog nooit gezien heeft en binnen 2 tellen aanwijst waar het probleem zit. Datzelfde treed ook op als je je eigen spul test. Het enige verschil tussen een senior en een junior is dat een senior zo'n situatie sneller inziet en dus eerder een collega raadpleegt of tijdelijk wat anders gaat doen om uit die gedachtetrein te komen.

Tip: huur iemand in die er verstand van heeft ...... de bouwkundige staat van je huis laten keuren door de bakker is ook niet goed..... het opstellen van het rapport is nog een het meeste simpele gedeelte, daarnaast is natuurlijk de vraag hoe betrouwbaar jou rapport als je al op een forum moet gaan vragen hoe zoiets moet ..... Als je slim bent huur je iemand anders in. Als je het dan toch zelf wilt doen dan moet je je laten opleiden, als dit niet mogelijk is of je wilt het toch gaan doen met de informatie die je kant vinden, kun je het denk ik beter niet doen voordat je een verkeerde beeld schets van de daadwerkelijke situatie en dan heb je kans dat je verder van huis bent ...

1. Begin maar eens om te kijken wat er zo al aan sql statements wordt toegelaten en schrijf gewoon op dat het geparameteriseerd moet worden en vervangen door stored procedures. (BELANGRIJK!)
2. Constateer dat jullie nog http ipv https gebruiken en dat zo snel mogelijk moet worden geïmplementeerd.
3. Constateer dat vanwege de reclame inkomsten er wel erg veel links naar derden zijn en dat we dat beter onder eigen naam kunnen doen (gestressde bedrijfsjurist tot gevolg)

Kost meestal 10 minuten en is helaas in 85% van de gevallen waar.

Ik ben het zowel met SirDice als met Erik van Straten eens ..... In 27001 moet je namelijk zelf controles doen (interne audit) en uiteindelijk wordt je daarop ook weer gecontroleerd door een externe auditor, dit is mogelijk ook hoe je netwerk zou moeten testen.

Om het makkelijk te houden zou je bijv. geautomatiseerde scans (livescan) uit kunnen voeren over je internet netwerk. Je hebt dan een globaal idee waar de zwakheden van je netwerk en deze je kunnen dichten en nader hand nog eens door een externe partij te laten controleren, echter is het natuurlijk belangrijk dat jullie dezelfde aandachtspunten hebben. Dus niet dat jij de scan op je internet netwerk uitvoert (LAN->LAN) en de externe partije en scan op buitenkant van je netwerk (WAN-LAN)

Toch blijf ik er bij dat je moeten weten waar je mee bezig bent, heb je geen inhoudelijke security kennis laat deze klus dan over aan iemand anders of laat je opleiden

Lijkt mij inderdaad niet meer dan logisch dat via PDCA de check neerkomt op een constante:
- interne audit
- externe audit

De interne kan je zelfs nog vaker uitvoeren dan de externe audit. Kort gezegd komt elke controle (heb ik dit wel goed gedaan?) neer op een interne audit. Wel een goed idee om het management alvast voor te bereiden op een externe audit (voornamelijk de kosten).

Blindstaren gebeurt ook bij routine. Echt een seniorenkwaaltje (kijk maar bij politieonderzoek).

Misschien dit een idee: http://www.securitycompliances.com/

"1. Begin maar eens om te kijken wat er zo al aan sql statements wordt toegelaten en schrijf gewoon op dat het geparameteriseerd moet worden en vervangen door stored procedures. (BELANGRIJK!)"

Belangrijk ? Je weet niet eens of hij een SQL database gebruikt. Je kent de scope van het onderzoek niet.

"2. Constateer dat jullie nog http ipv https gebruiken en dat zo snel mogelijk moet worden geïmplementeerd."

Heeft het onderzoek betrekking op een website dan ?

"3. Constateer dat vanwege de reclame inkomsten er wel erg veel links naar derden zijn en dat we dat beter onder eigen naam kunnen doen (gestressde bedrijfsjurist tot gevolg)"

Lol, hoe kom je hier in hemelsnaam op.

PDCA komt eigenlijk niet neer op het uitvoeren van interne en externe audits ....... het uitvoeren van de audits vormen een onderdeel van een aparte PDCA-cycles die natuurlijk een onderlinge relatie met elkaar hebben. Het uitvoeren van de audit is al het ware de C in de PDCA-cycles.

Niet elke controle is een interne audit, een interne audit is omvangrijker en dit vooraf afgebakend te zijn met bijv. aandachtspunten. Deze aandachtspunten kunnen bijv. de uitkomsten en verbeteracties uit de vorige audit zijn.

De kosten van de externe audit zijn een goed punt om vooraf bij de directie of het betreffende management aan te geven zodat deze meegenomen kunnen worden in de begroting, de kosten van een externe audit zijn afhankelijk van de grote en de structuur van de organisatie. Aan de hand daarvan wordt het aantal audit dagen vastgesteld, meestal moet je bij een "midden" bedrijf rekening houden met minimaal 10 000 euro aan kosten voor de externe audit. Belangrijk is dat de partij die de audit uitgevoerd geaccrediteerd door de raad van accreditatie, dit is belangrijk voor de waarde van het certificaat.

Voor zover ik weet slaat de Check toch echt op controle (intern/externe audit en eigen controle (idd geen interne audit)).
Je kunt het begrip PDCA zo ruim of beperkt gebruiken als je zelf formuleert. In een ruim begrip valt onder de C ook de externe audit (die dan weer zijn eigen PDCA-cyclus heeft).

Heel kort door de bocht valt PD dan onder het interne stuk en CA voor het externe gedeelte. Het heeft natuurlijk wel overlappingen (zoals de dubbele interne/externe audit).