Dit kan je niet in een aantal zinnen samenvatten.
Het is afhankelijk wat de beleidslijnen zijn binnen in de organisatie.
Security model die er wordt gehanteerd etc.
Zou je eerder adviseren om langs de security officer te gaan en met hem een gesprek hierover te hebben.

Bedankt voor je reactie. Ik begrijp dat dit niet in een aantal zinnen is samen te vatten. Daarom vraag ik me af of er een methode bestaat die ik kan toepassen om dit zo sluitend mogelijk te beschrijven. Helaas bied je reactie geen oplossing voor mijn uitdaging.

SirDice, Spatieman enig idee wellicht?

bl33p

Ik zou je adviseren om een technische risicoanalyse te schrijven volgens het volgende model:

- Concept: Wat staat er en voor welk doel, inclusief de beveiligingaspecten
- Beschrijving van de onderkende dreigingen: Hacken, (D)Dos, Lekken van data, virussen, etc.
- Beschrijving van de getroffen maatregelen: Hoe worden de onderkende dreigingen gemitigeerd (maw welke maatregelen heb je getroffen om het risico te beperken)
- Beschrijving van het restrisico

Succes!

Je zou de ISO (27002 / 2) richtlijnen kunnen hanteren en vervolgens daar een beschrijving op kunnen baseren.

Neem het beveiligingsplan in de hand en loopt de specifieke situatie punt voor punt af. Maar ja, als het plan k*t is zal jouw aandeel niet veel beter worden.

Beste bl330p,

Security analyse is een vak apart. Het is vooral de vraag wat je werkgever van je verwacht.

Met de handreiking die anoniem@12.51maakt, kan je uiteraard best wat basiszaken in kaart brengen. Als je werkgever van je verwacht dat jouw risicoanalyse een professioneel en sluitend document wordt, dan moet je je afvragen of je dit (gezien je vraagstelling) zelf moet willen schrijven. Wellicht doe je er dan verstandig aan om expertise op dit gebied in te huren.

Zorg ook dat je weet welk doel je werkgever met deze risicoanalyse heeft en dat je inzichtelijk hebt hoe groot de impact van een securitylek op betreffende server is. Als die vol staat met klantgegevens en deze wordt later gehackt op een wijze waar jouw analyse niet voorzien heeft, heb je dan wel/geen probleem?

Het eerdere genoemde ISO 27002 is inderdaad een leuke kapstop om het security model vorm te geven.

Andere kapstokken die je kunt overwegen zijn Cobit, NIST.

In tegenstelling tot het door jou genoemde ITIL geven ISO en NIST concretere normen waaraan je security niveau kunt toetsen. Cobit is meer op basis van best practices en biedt in mindere mate concrete normen.

Succes!

Bedankt Anoniem daar heb ik wat aan! Ik ben weer een stapje verder. Weet je toevallig ook een document wat ik wellicht als template/richtlijn kan gebruiken. Ik zie er heeel veel staan op b.v. http://www.iso27001security.com maar zie door de bomen het bos niet meer. Iemand?

bl33p

Ad hand vd functionele eisen (die in principe rekeing hielden met de risks) beschrijf je de technische implementatie.


Klaar.

Risico 1: bl33p moet een stukje over beveiliging schrijven van een server maar weet niet hoe dit te omschrijven. Dus de beveiliging voor die server is nog nooit 'goed' omschreven?

Hello bl33p
Je zou ook het OSI model (van datacom) als kapstok voor je security beschrijving kunnen nemen:
Hier alvast een "raamwerk" als opzetje, de detail mag je zelf invullen

1. FYSIEK
(Hoe is de server zelf afgeschermd van de boze buitenwereld op Hardware_level:)
- Is de server-kast zelf afgesloten met sloten
- Hoe zit de server vastgeschroefd in het betond van het gebouw
- Staat deze serverkast achter slot en grendel
- Hoe werkt het slot naar de serverkast (hangslot, keycard)
- Waar bevind zicht de serverkast (in een gebouw, kluis)
- Hoe kom je daar, vanbuitenaf binnen (portier, vingerprint_id, iris_scan)
Dus welke afweer middelen staat er tussen e serverkast en de boze buitenwereld op de stoep van het gebouw

2. Dan ga je een laag verder (de serverkant in van buiten naar binnen)
- Is het BIOS van de sever beveiligde met een wachtwoord

3. OPERATINGSYSTEM - LOGIN NIVO:
- Moet je wel/niet inloggen op de server_console
- Welke soort en smaak passworden en password lengtes worden er gebruikt
- Hoe worden de pasworden beveiligd tegen diefstal (cryptografeers of niet)

3. OPERATINGSYSTEM - SYSTEEM NIVO:
- Hoe stabiel is het operating system(OS)
- Word het regelmatig gepatched door fabrikant
- Welke "gaten" zitten erin (rotte services, dll's kernel-hooks)
- Hoe 'secure" staat het OS bekend in de ict_business
- Hoe vaak zijn er hacks aan het ligt gekomen van dat type OS
>
- Hoe is het filesystem ingericht en beveiligd
- Hoe is de backup geregeld (in geval van systeem crash)
- Hoe Is de server uitgerust met digitale ondierte bestrijdings software (virus, malware, spyware, keyloggers)
- hoe staat het met de logfiles (hoe lang worden ze bewaard, wat staat erin)

4. NETWERK NIVO
- Is er een firewall aanwezig op internet verbinding (yes/no)
- Hoe is de firewall ingesteld (welke poorten staan open, dicht en waarom)
- Welke "internet verbindings-risicio's zijn er
- Draait er wel/geen inbraak detectie systeem mee op de server?
- Hoe (protocollen) en tegen wie (andere servers, clients) communiceert de server:
--> Binnen de DMZ
--> Van DMZ naar internet
--> Van DMZ naar intern- netwerk

5. APPLICATIE_NIVO:
- Welke OS services, daemons draaien er op je server en wat doen ze precies?
- Welke programma's draaien er op je server
- Via welke netwerk, verbindingen (Zoals udp, tcp-ip poorten) praten die programma's met andere pc,servers..

Volgens mij schiet je zo al een aardig einde op om een overzicht te beschrijven van de server in je DMZ
Good luck met je beschrijving

Dev_0

+1 en kuddo's voor Dev_0

Hiermee heb je me echt super geholpen! Bedankt voor je feedback. Ik kan aan de slag!
Ik doe je raamwerk even opslaan op /home/raamwerk en niet /dev/null/raamwerk als je het niet erg vind ;)

Thanks again!

bl33p

Beperk je document niet alleen tot de techniek rondom de server..
Maar betrek en ook de huidige bedrijfs processen in die aangepast moeten worden om de server veilig te kunnen laten blijven voor de komende periode.

De eerder genoemde nen normen zijn inderdaad goed te gebruiken als handvat.

Security is item waar veel haken en ogen in zitten maar erg belangrijk is,

http://www.tns.com/rev_2_SF/SFv1.html

Wat is de bedoeling van het document:

Security beleid (algmeen)
Security baseline
Beleid mbt inrichting en gebruik van DMZ componenten.
Standaard inrichting van DMZ componenten maar dan de technische inrichting en configuratie.
Een standaard beheer document van DMZ componenten. (wie doet wat en mag wat. Wat te doen bij een configuratie aanpassing, etc)

De methode iso27005 voor het Risico Management proces. dit geeft je inzage in welke maatregelen een bedrijf nog heeft.
De ISO 27002 kan je gebruiken voor de security controls, beleid & baseline. Echter de iso doet geen concrete configuratie voorstellen.
Ook cobit / coso geeft controls maar dat is meer voor banken / beursgenoteerde bedrijven.
De ISO 27001 is de norm indien je op security management wil certificeren en maakt gebruik van de iso27002.

NIST / sans en govcert geven je richtlijnen voor o.a. de inrichting en configuratie van verschillende technische componenten.
Daarnaast kan je bij de leveranciers van de techniek (microsoft, apache, Cisco, etc) configuratie voorstellen vinden voor DMZ en inethost.

Dus afhankelijk van het type document dien je bij meerdere normen te gaan shoppen en cherry-picken.
Daarnaast zoeken op internet naar template doet wonderen, want je bent niet de eerste met deze uitdaging.

Suc6 met de doc's.

SOFAR RFV

Mensen, waar zijn we nu mee bezig? Er komt iemand langs die is gevraagd over de beveiliging te rapporteren van een server maar van toeten noch blazen weet. Vervolgens komt er een parade aan 'helpers' langs die de ene na de andere suggestie hebben.
Als je hier al moet komen vragen hoe je over de beveiliging moet rapporteren is er flink wat mis. Maar het schokkendst vind ik de berg aan reacties waarbij het leeuwendeel graag een berg informatie laat zien van 'zo kan het' maar zich niets aan lijkt te trekken van de onderliggende probleem dat iemand die dit al moet vragen kennelijk iets moet doen wat weinig bij zijn professionele pakket blijkt te horen. En dat terwijl beveiliging en er over rapporteren geen zaken zijn die je even op een forum wel met een miniem stukje vraag-antwoord recht kan trekken.
Maar deze opmerking zal me waarschijnlijk wel weer negatieve punten opleveren - zoals ieder ander die hier kritisch reageerde op de vraag. Wanneer gaan we beveiliging eens serieus nemen?

Ik ben het met RaceAap eens: het grootste lek in veel beveiliging zijn de mensen.

Je kunt nog zo'n goed slot op de deur hebben, maar als de portier de sleutel aan iedereen uitleent die erom vraagt (en een diep decolletee heeft ";-) levert dat weinig op.

- wie kunnen er bij de server?
- wie beheren het OS/applicatie?
- hoe vaak wordt er iets op dat ding gecheckt?
- hoe 'security-aware' is de organisatie?

Helemaal mee eens. Wat denk je zelf: je schrijft iets - maar weet nog niet wat precies wat is - en er komt later onheil. Wie denk je zal als eerste worden aangesproken? Sorry, maar goed bedoelende hobbisten heeft deze bedrijfstak al teveel voortgebracht. Zelfs de van oorsprong professionele vereniging als het PvIB heeft tegenwoordig een algemeen gehalte dat zo bedroefend is dat ik niet meer op bijeenkomsten kom. Gelukkig zijn de stukjes die ze publiceren nogwel te verteren.

Frans.

@Anoniem_n??:
Wat is er mis aan kennis delen met mensen die van je willen leren?

Waarom zie je het zo zwartgallig, zwaar, negatief? Geziend de reacties en de inhoudelijke deskundigheid van velen in dit forum (mijn complimenten daarvoor collega's) zou ik als ict-buitenstaander ook mijn vraag hier willen stellen.
- Niet geschoten is altijd mis toch?
- Nee heb je en Ja kun je krijgen!
- Van vragen word je wijs(zer) ;-)

So what? Wat is daar mis mee?

Mag ik vragen jou jij zelf je loopbaan bent begonnen in dit veld?
Hopenlijk ook door op zoek te gaan en te vragen naar antwoorden of richtingen die je zelf nog niet hand ontdekt

Mag ik je vragen" Waarom niet?
Zolang je geen inhoudelijke zaken blootgeeft over hetgene waarover je rapporteert, zie ik er geen enkel kwaad in om een vraag te beantwoorden Anoniem. Of zie jij dat anders en waarom dan?

Aan de andere kant - als ict pro - begrijp ik je bezorgdheid volledig. Beveiliging is en blijft mensenwerk en dat zijn meteen de zwakste schakels in het geheel. Wat security is meestal niet iets waar mensen over praten, mee te koop lopen.

Wat je je ook af kunt vragen bij IEDERE vrager op dit forum:
- Wat hoe weet je wat de vrager wel/niet gedaan heeft.
- Komt ie er makkelijk mee weg.
- Wil ie er zelf niets voor doen
- Had de vrager geen security-professionel moeten inhuren?
- Bespaart hij,zij zo op de kosten?
In dat geval ben je er zelf ook nog bij om te beslissen om wel/geen antwoord te geven toch? The choice ic yours.

Echter....Hebben we zelf niet het eeuwige leven...
Dus is het handig om de jongere generatie of de beginnende mensen in de security industrie onze opgedane kennis over te dragen (zo kijk ik er tegenaan ) Ik vind het fijn om zoveel mogelijk van mijn kennis te delen, want wat heb ik zelf an als ik straks "weer naar huis toe mag"?

Rule #1, #2 : van de hacker Ethic (http://en.wikipedia.org/wiki/Hacker_ethic)
1 - Access to computersand anything which might teach you something about the way the world worksshould be unlimited and total. Always yield to the Hands-On Imperative!
2 - All information should be free.

Final word: "Met het hebben van kennis, komt ook de verantwoordelijkheid aan wie je het overdraagt ;-)"

--Off topic --
Dev Null, mooi gesproken :-)

-Remco

Pak de ISO27002 erbij, loop alle richtlijnen door en beschrijf van alle relevante richtlijnen de status. Samenvatten en rapporteren die hap, klaar. Dat is het makkelijkst. Ze noemen dit een quickscan. Als je dit voor het eerst doet, dan ben je er zo'n twee maanden mee bezig, de volgende doe je in een paar dagen.

Een andere mogelijkheid is een kwalitatieve risicoanalyse uitvoeren, waarbij je de kans en schade inschat van verschillende bedreigingen. Methodes die hierbij gebruikt worden zijn bijvoorbeeld de fault-tree analyse en de A&K analyse. Voor het verzamelen van gegevens wordt vaak de Delphi techniek gebruikt. Het is allemaal een stuk ingewikkelder dan mijn eerste voorstel, ik zou er zonder hulp niet aan beginnen.

Of je beschrijft gewoon de beveiliging naar eigen inzicht, dat kan ook. Betrouwbaar is het waarschijnlijk niet, maar je kan het wel in een paar dagen af hebben. Het ligt er maar net aan wat management nou eigenlijk wil.

Je kan ook een baseline document schrijven voor de dmz servers, Daarin wordt beschreven welke services uit staan, hoe de auditing staat, welke password policies er gelden, etc etc etc. Je hebt bij Micosoft of bij de NSA een zooi security hardening white papers die je kan gebruiken om dit soort documenten te beschrijven.

Ook handig is wellicht de Security Compliance Manager die je kan vinden op :
http://technet.microsoft.com/en-us/library/cc163140.aspx
Hierin staat advisories die je kan volgen, je kan ook je eigen advisories maken en deze verwerken in group policies of domain policies.

NSA documentatie en configuration guidance kan je hier vinden.

http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml

De NSA guidance is ideaal voor SoX en SAS 70 systemen van multinationals die beursgenoteerd zijn of simpelweg een van deze certificeringen wil hebben om zo andere multinationals te kunnen servicen. meestal maak je alsnog wijzigingen in deze NSA guidance configs, maar het helpt je een eind op weg.

je kan RFC2196 ook eens doornemen, het geeft je misschien nog goede ideeën

Er kan dus van alles. Misschien je werkgever eens laten beschrijven wat hij nu precies wil en waarom. Gewoon terugkaatsen die bal, doe ik ook altijd :)

Bl33p,

Kijk samen met de lijst van DevNull eens op http://www.classity.nl/security-controls.html. Hierin staan wat basic zaken waar je rekening mee kunt houden bij bijv. het hardenen van je systeem. Hiermee kom je al een heel eind. Als het een webserver betreft kan het aardig zijn om mod_security te overwegen.

Succes!

Tja, als je blijkbaar niets van beveiliging af weet en je werkgever daar blijkbaar niet op stuurt wordt het een lastige situatie.
Zeg gewoon eerlijk dat je van beveiliging geen verstand hebt, op dit moment, maar dat je jezelf er graag in wilt specialiseren en stel een opleidingstraject voor. Doe je meteen wat aan je ontwikkeling.

Het is altijd lekker makkelijk om iemand die kritiek heeft te pogen af te schieten met woorden dat de persoon zwartgallig is en een berg tegenvragen op te werpen. Laat ik de reactie naar zulke personen dus maar kort houden, want het lijkt verspilde moeite om de situatie uit te leggen aan personen die geen zin hebben in een helicopterzicht. Ja, geweldig dat kennis delen, allemaal antwoorden uitspuwen en laat de vrager maar gaarkoken want ieder kan wat leren. Het gaat mij er om dat iemand zich voorstelt als een professional en vervolgens een hele berg aan onbekenden zijn/haar als hulp zijn kennis uitstort om te 'helpen'. Ja, wiens nut dienen we dan? Kennelijk dat van de 'helpers' die vol goede bedoelingen perse een antwoord wil opgooien en dan roept dat kennis macht is en vrijheid om er wat zinnigs mee te doen slechts de verantwoordelijkheid van de vrager. Ongeacht of je nu veel of weinig weet, wat je vind wat iemand met informatie moet doen: antwoorden uitspuwen en jezelf verdedigen is niet hetzelfde als helpen. We hebben het hier over veiligheid: nemen we dat liever serieus of vinden we onszelf als raadgever belangrijker dat we maar alles gaan roepen? Mijn punt: kijk verder dan de vraag voor je probeert te 'helpen' en denk niet enkel aan je eigen belang en mening als het om helpen gaat. Ik heb al veel aan beveiliging de soep zien lopen omdat 'helpers' vonden dat het uitstorten van hun kennis belangrijker werd bevonden dan het onderliggende probleem. En dat terwijl de beveiliging het doel was.... Wat is ego toch een lastig risico.

Beste Anoniem,

Ik heb de http://www.classity.nl/security-checklist.html?securitychecklist=webserverhardening checklist doorgenomen. Mijn servertje voldoet hier aan. Bedankt voor je nuttige post, het is een van de weinige tussen al die azijnpissers. Zo kom ik stap voor stap bij een goed document. Nogmaals bedankt!

bl33p

Mooi vooroordeel Anoniem.. verklaar je nader....Ik ben benieuwd wat bedoel je precies met helikopter inzicht, want voor mij is mij niet duidelijk. Wat zijn je argumenten?

Zover het ik niet gekeken en zo diep heb ik het niet onderzocht, ik zag een vraag en antwoordde hierop. simpel.

Waarschijnlijk de vrager, want die was op zoek naar een antwoord.

Wederom verkeerd begrepen door je.
Als je goed leest is het de verantwoordelijkheid van de beantwoorder (in jouw context 'helpers") om zich bewust te zijn van de overgedragen kennis aan een vrager. Simpelweg om je - als 'helper' - totaal geen controle hebt wat de vrager met je antwoord gaat doen.

Wat is jou definitie van helpen dan, wat blijkbaar verschil je daarin van opvatting met de rest?
- Je kunt iemand een richting aangeven, zodat ie de rest zelf kan uitzoeken
- Je kunt ook iemand een complete oplossing voorkauwen
- Je kunt ook jezelf laten inhuren en de klus van iemand overnemen.
Daar leert ie zelf niet van lijkt mij)
Dus ... je definitie van helpen is - imo - afhankelijk van de andere,vragende partij

Dus als ik je argumenten goed begrijp, moet iedere vragen het zelf maar uitzoeken, want daar worden ze wijzer van?

Dat is jouw persoonlijk ervaring en hoeft niet gelijk te zijn aan de ervaringen van andere 'helpers"


Dit is mij nog net precies duidelijk wat JIJ er precies mee bedoeld Anoniem.
Wat ik ut je reacties heb begrepen is dat je
- het stoort dat iemand zich als beveiliging expert profileert, maar dat - in jouw ogen - helemaal niet schijn te zijn.
- dat andere mensen / 'helpers' hier niet zo op reageren als jijzelf zou doen
Klopt dat tot zover?


Klopt helemaal Anoniem,
Laat ik het zo zeggen, we hebben allemaal een persoonlijk BIOS, maar de inhoud is verschillend.
Want onze ego's zijn allemaal anders gehersenspoeld tijdens onze reis over deze aardbol ;-)

De kunst is dus ook om 'dat ego" op tijd terug te doen in zijn hokje :-P en open en oprecht te leren werken aan samenwerking, communicatie en open staat voor elkanders argumenten (en niet de onderliggende emoties :-))

Ik ben benieuwd naar je antwoorden, tegenargumenten Anoniem
Hierdoor kan mijn ego weer wat van je opsteken, leren

Dev_0