Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Reacties (24)
Leuk artikel, maar de argumentatie sluit niet aan bij de feiten. Bijvoorbeeld dat de nieuwe leiding beter naar klanten zou luisteren. Daar is duidelijk niets van gebleken. Het is geen arrogantie, het is in extremis doorgevoerd eigen belang met een centraal plan van veel geleidelijke stappen om tot ergens te komen (de centraal bestuurde computer en vermarketing van gestolen privacy).
Door Rinjani: The one word that always comes up is arrogance.
Everyone in the industry, whether they used to work at Microsoft or not, almost always includes arrogance among their top reasons for the problems with Update. [1]
[1] https://www.extremetech.com/computing/242808-microsoft-hasnt-fixed-windows-update
Everyone in the industry, whether they used to work at Microsoft or not, almost always includes arrogance among their top reasons for the problems with Update. [1]
[1] https://www.extremetech.com/computing/242808-microsoft-hasnt-fixed-windows-update
Kan je misschien ook niet een conclusie posten in het Nederlands? Ik heb geen zin om aan dit soort online posters posts mee te werken. Zo is er geen discussie te voeren.
22-01-2017, 16:46 door
karma4
Het is dezelfde arrogantie als ook in het OSS geloof. Dus wat is het wezenlijk verschil. Kat en Hond bijten beide.
24-01-2017, 09:31 door
[Account Verwijderd]
[Verwijderd]
Rinjani je hebt de standaard reactie van oss adepten toch vaak genoeg gezien. Ernstige fouten van jaren oud worden gefixed uh nee krijgen een pleister. De fout en het probleem worst niet begrepen als er maar een fix te downloaden staan ze te juichen hoe goed het is.
Ken je de wereld van het grote geld met de IT leveranciers,dan zie je dat er van alles binnen gereden wordt met zeer veel oss onder in de machinekamer van die grote as-service tools delen.
Hoe dat bijgehouden en gecontroleerd moet worden verdwijnt verrassend snel onder het vloerkleed.
De verkoper schermt met ... en de manager laat het er bij.
Oracle ibm Apple accenture Cisco sap tibco redhat suse canonical(sorry voor de overgeslagenen) het maakt echt niet veel uit. Het gaat ze allemaal om de verdiensten.
Piet ik heb de leestekens spaties alinea ruimtes toegevoegd. Dat zijn dingen die je er snel bij zet in leets.
Ken je de wereld van het grote geld met de IT leveranciers,dan zie je dat er van alles binnen gereden wordt met zeer veel oss onder in de machinekamer van die grote as-service tools delen.
Hoe dat bijgehouden en gecontroleerd moet worden verdwijnt verrassend snel onder het vloerkleed.
De verkoper schermt met ... en de manager laat het er bij.
Oracle ibm Apple accenture Cisco sap tibco redhat suse canonical(sorry voor de overgeslagenen) het maakt echt niet veel uit. Het gaat ze allemaal om de verdiensten.
Piet ik heb de leestekens spaties alinea ruimtes toegevoegd. Dat zijn dingen die je er snel bij zet in leets.
24-01-2017, 13:07 door
PietdeVries
Door karma4: <snip>
Karma, kerel - daar is geen touw aan vast te knopen... Haal even rustig adem en probeer het nog eens.
24-01-2017, 22:21 door
Ron625
Door karma4:
Oracle ibm Apple accenture Cisco sap tibco redhat suse canonical(sorry voor de overgeslagenen) het maakt echt niet veel uit. Het gaat ze allemaal om de verdiensten.
Debian?Oracle ibm Apple accenture Cisco sap tibco redhat suse canonical(sorry voor de overgeslagenen) het maakt echt niet veel uit. Het gaat ze allemaal om de verdiensten.
Dat is geen bedrijf, en staat bekend als zeer veilig, zo niet de veiligste.
25-01-2017, 08:03 door
karma4
Door Ron625: Debian?
Dat is geen bedrijf, en staat bekend als zeer veilig, zo niet de veiligste.
Ok je hebt iets serieus https://www.debian.org/intro/about het wordt gedraaid door vrijwilligers. Het bouwt weinig zelf geheel opnieuw op maar bundelen 43000 van elders gekopieerde code. Ze noemen linux kernel (redhat). Dat is geen bedrijf, en staat bekend als zeer veilig, zo niet de veiligste.
Het geheel heeft iets vrijblijvends, geen inkomsten en ook geen garanties of verhaalmogelijkheden. Daarmee valt het vaak af als die garanties en support wel nodig zijn.
Door die afhankelijkheden met code kopiëren kopieer je ook alle fouten mee en je introduceert nieuwe. Nu zal die gemeenschap een bepaald gedrag vertonen. Daarmee zijn ze als doelwit mogelijk ook anders.
Doe je de bewering veiliger dan zou dat onderzocht moeten worden met gelijkwaardige groepen en soort gebruik.
Ik heb altijd een hekel gehad aan verkondigde waarheden die niet wasr bleken maar enkel anekdotisch onderbouwd bleken.
Erg veilig dat Debian?
Eens kijken op hun eigen site:
https://security-tracker.debian.org/tracker/status/release/stable
Het meest veilig besturingssysteem is No-Os
Eens kijken op hun eigen site:
https://security-tracker.debian.org/tracker/status/release/stable
Het meest veilig besturingssysteem is No-Os
Door karma4:Het bouwt weinig zelf geheel opnieuw op maar bundelen 43000 van elders gekopieerde code.
Door Anoniem: Erg veilig dat Debian?
Eens kijken op hun eigen site:
@Karma: Er is ook een terugkoppeling, zo worden b.v. de aanpassingen door Canonnical (Ubuntu) aan de Debian gemeenschap gegeven en er zijn meer betrouwbare bronnen.Eens kijken op hun eigen site:
Het is dus niet (alleen) kopieren, maar eerder samenwerken aan.
@Anoniem: Heb je ook de pakketten en meldingen bekeken?
Bijna alle meldingen zijn gewone bugs en hebben niets met de veiligheid te maken.
Daarbij is voor de meeste veiligheidslekken fysieke toegang nodig, iets waar ieder systeem gevoelig voor is.
25-01-2017, 21:42 door
[Account Verwijderd]
[Verwijderd]
Geloof je het zelf Rinjan? Je bewering lijkt waarachtig meer op een geloofsbelijdenis dan een echte onderbouwing, redenering met controleerbare argumenten.
Ron daar kom je met argumenten waar We niet kunnen zeggen of het sterk of zwak Is. Terugkoppeling van problemen naar leveranciers Is heel gewoon en wordt als samenwerking gezien. Dat Is ook in de commercie zo.
Inderdaad het geld ook voor aale software inclusief os.
Het wezenlijks te stap je aan voorbij, de aansprakelijkheid met verantwoording afleggen.
Ron daar kom je met argumenten waar We niet kunnen zeggen of het sterk of zwak Is. Terugkoppeling van problemen naar leveranciers Is heel gewoon en wordt als samenwerking gezien. Dat Is ook in de commercie zo.
Inderdaad het geld ook voor aale software inclusief os.
Het wezenlijks te stap je aan voorbij, de aansprakelijkheid met verantwoording afleggen.
Helaas heeft Microsoft in 2014 het roer omgegooid m.b.t. het testen van hun software en updates. Een grote groep medewerkers die voor testen verantwoordelijk waren zijn ontslagen. De nieuwe strategy is de gebruiker laten testen. Dat is ook een van de redenen voor verplichte updates en telemetry in Windows 10. Ze hebben die feedback nodig, want ze testen dit niet meer in huis zoals ze vroeger deden.
Door Anoniem: Helaas heeft Microsoft in 2014 het roer omgegooid m.b.t. het testen van hun software en updates. Een grote groep medewerkers die voor testen verantwoordelijk waren zijn ontslagen. De nieuwe strategy is de gebruiker laten testen. Dat is ook een van de redenen voor verplichte updates en telemetry in Windows 10. Ze hebben die feedback nodig, want ze testen dit niet meer in huis zoals ze vroeger deden.
Nu is er alleen nog een verplichte klantenbinding nodig om te voorkomen dat de mensen weglopen van Windows. Maar daar is al in voorzien: UEFI zorgt hiervoor waar het registratienummer van Windows onuitwisbaar in opgenomen is. Als je je pc alleen nog hiermee kunt opstarten, is de klantenbinding perfect.
26-01-2017, 11:01 door
Ron625
Door karma4:Ron daar kom je met argumenten waar We niet kunnen zeggen of het sterk of zwak Is.
Terugkoppeling van problemen naar leveranciers Is heel gewoon en wordt als samenwerking gezien.
Je draait het om.Terugkoppeling van problemen naar leveranciers Is heel gewoon en wordt als samenwerking gezien.
In dit geval gaat het niet om de terugkoppeling van problemen, maar van terugkoppeling van oplossingen en verbeteringen.
Bekijk ook eens het update/upgrade gebeuren van diverse besturingssystemen, Microsoft doet het (meestal) 1x per maand.
De meeste andere systemen doen het, zodra het beschikbaar is, zeker met een beveiligings-update moet je niet wachten.
Zelf controleer ik 3x per dag of er upgrades zijn voor mijn systeem, en meestal is het raak.
Bijna altijd zijn het verbeterpunten, die niets met veiligheid te maken hebben, dat komt o.a. omdat het systeem waar ik mee werkt pas over 3 maanden wordt vrijgegeven, er zijn nu eenmaal idioten nodig om het te testen :-).
Om een probleem te kunnen aanpakken moet je eerst weten dat er een probleem is. Black box testen is vanuit het onbekende een hopeloze zaak omdat je niet wens weet waarnaar te kijken. White box testen is al uitdagend genoeg met bekende situaties daar moet je nog zeer veel samenvoegen om de testvaruaties in te perken tot iets werkbaars. Kijk eens bij http://www.istqb.org/ voor achtergronden.
Als je meelift op updates en enkel daarnaar kijkt, dan vertrouw je op anderen om de issues te vinden en aan te kaarten.
Je moest eens weten wat er allemaal te zien Is en wat niet aangemeld kan of mag worden omdat de bron onfeilbaar is of omdat het geheim is.
Een fraaie: nee die fout staat niet in ons systeem u bent de eerste die zoiets meld dus u zit fout we nemen het niet aan.
(Prof service tools op servers multiplatform multi tier)
In een operationele omgeving is elke verandering een bedreiging waar je voorzichtig mee moet omgaan. ITIL soms zo doorgedraaid dat certificaten vervangen al bijna onmogelijk is. Afwachten testen en op een geschikt moment doorvoeren is de beste Weg. Alleen bij hoge uitzondering iets wat meteen moet. Als het een maandje kan wachten omdat het risico van de change hoger is dan het risico door fouten te laten zitten dan is dat gbv. (Gezond boeren verstand)
Als je meelift op updates en enkel daarnaar kijkt, dan vertrouw je op anderen om de issues te vinden en aan te kaarten.
Je moest eens weten wat er allemaal te zien Is en wat niet aangemeld kan of mag worden omdat de bron onfeilbaar is of omdat het geheim is.
Een fraaie: nee die fout staat niet in ons systeem u bent de eerste die zoiets meld dus u zit fout we nemen het niet aan.
(Prof service tools op servers multiplatform multi tier)
In een operationele omgeving is elke verandering een bedreiging waar je voorzichtig mee moet omgaan. ITIL soms zo doorgedraaid dat certificaten vervangen al bijna onmogelijk is. Afwachten testen en op een geschikt moment doorvoeren is de beste Weg. Alleen bij hoge uitzondering iets wat meteen moet. Als het een maandje kan wachten omdat het risico van de change hoger is dan het risico door fouten te laten zitten dan is dat gbv. (Gezond boeren verstand)
26-01-2017, 12:29 door
karma4
[Verwijderd]
Door Ron625:
Bekijk ook eens het update/upgrade gebeuren van diverse besturingssystemen, Microsoft doet het (meestal) 1x per maand.
De meeste andere systemen doen het, zodra het beschikbaar is, zeker met een beveiligings-update moet je niet wachten.
Zelf controleer ik 3x per dag of er upgrades zijn voor mijn systeem, en meestal is het raak.
En hoe wil je dit in een Enterprise doen? Even een update installeren en daarna je systemstack controleren. En tijdens de test, is er al weer een nieuwe update. Bekijk ook eens het update/upgrade gebeuren van diverse besturingssystemen, Microsoft doet het (meestal) 1x per maand.
De meeste andere systemen doen het, zodra het beschikbaar is, zeker met een beveiligings-update moet je niet wachten.
Zelf controleer ik 3x per dag of er upgrades zijn voor mijn systeem, en meestal is het raak.
Hier zit juist niemand om te wachten, het is niet beheersbaar.
Men wil daarbij juist voorspelbaarheid hebben, want dat is te beheren en te plannen. 2de dinsdag van de maand updates, dus je weet wanneer je onderhoud moet plegen en kan plegen. Je kunt dus al een jaar vooruit plannen en overige changes hierop afstemmen.
Hi,
https://security-tracker.debian.org/tracker/status/release/stable
Dit zijn bijna allemaal vulnerability's (CVE's), dus security kwetsbaarheden in onderdelen van Debian. Even los van welk OS beter of slechter is, het zijn er best veel voor iets waarvan sommige zeggen dat het veilig en dus minder kwetsbaar is.
Risico wordt vaak aangeduid als "risico = kans x schade"
De kans is een combinatie van het aantal kwetsbaarheden in een OS en de hoeveelheid gebruikers waardoor het voor een hacker interessant wordt zich te richten op een bepaald OS.
De schade is de mate dat een hacker iets kan bereiken, schade is beperkt als een applicatie het even niet doet (DOS), maar wordt groter als een hackers het systeem kan overnemen en/of data kan misbruiken. Dit laatste bereikt met vaak door het kunnen starten van eigen code van de hacker. In het volgende overzicht kan je zien hoe dit met Debian zit:
http://www.cvedetails.com/vendor/23/Debian.html
In 2016 zijn er 64 kwetsbaarheden gevonden welke konden worden gebruikt voor het uitvoeren van code. Ook dit is best veel.
Het enige wat overblijft waarom Debian veiliger zou zijn en je dus minder Risico loopt is de veronderstelling dat Debian minder wordt aangevallen door hackers. En dit kan best zo zijn.
Mgr,
No-oS
https://security-tracker.debian.org/tracker/status/release/stable
Dit zijn bijna allemaal vulnerability's (CVE's), dus security kwetsbaarheden in onderdelen van Debian. Even los van welk OS beter of slechter is, het zijn er best veel voor iets waarvan sommige zeggen dat het veilig en dus minder kwetsbaar is.
Risico wordt vaak aangeduid als "risico = kans x schade"
De kans is een combinatie van het aantal kwetsbaarheden in een OS en de hoeveelheid gebruikers waardoor het voor een hacker interessant wordt zich te richten op een bepaald OS.
De schade is de mate dat een hacker iets kan bereiken, schade is beperkt als een applicatie het even niet doet (DOS), maar wordt groter als een hackers het systeem kan overnemen en/of data kan misbruiken. Dit laatste bereikt met vaak door het kunnen starten van eigen code van de hacker. In het volgende overzicht kan je zien hoe dit met Debian zit:
http://www.cvedetails.com/vendor/23/Debian.html
In 2016 zijn er 64 kwetsbaarheden gevonden welke konden worden gebruikt voor het uitvoeren van code. Ook dit is best veel.
Het enige wat overblijft waarom Debian veiliger zou zijn en je dus minder Risico loopt is de veronderstelling dat Debian minder wordt aangevallen door hackers. En dit kan best zo zijn.
Mgr,
No-oS
26-01-2017, 21:14 door
[Account Verwijderd]
[Verwijderd]
26-01-2017, 23:06 door
karma4
Rinjani een gebed is ook een herhaling, daarmee nog geen waarheid of werkelijkheid. Het is een terukerende dubbele bodem die Eric Arthur Blair wilde laten zien ... bb...
27-01-2017, 07:28 door
[Account Verwijderd]
-
Bijgewerkt: 27-01-2017, 08:00
[Verwijderd]
27-01-2017, 08:24 door
karma4
Ah Rinjani je begint weer op de man te spelen.
Ik moest het even opzoeken. Aangezien je het paraat hebt moet het vaker tegen je aan gehouden zijn.
Van denkers kun je leren en met 1984 zie je dat betekenissen omgedraaid worden en niets Is wat het lijkt.
Het is zo'n verspilde moeite omdat ieder voor zich uit te moeten werken door eigen praktijkervaringen.
Ken je de achtergrond van karma in de filosofie. Let ook even op de meerdere stromingen en diepgang.
Ik moest het even opzoeken. Aangezien je het paraat hebt moet het vaker tegen je aan gehouden zijn.
Van denkers kun je leren en met 1984 zie je dat betekenissen omgedraaid worden en niets Is wat het lijkt.
Het is zo'n verspilde moeite omdat ieder voor zich uit te moeten werken door eigen praktijkervaringen.
Ken je de achtergrond van karma in de filosofie. Let ook even op de meerdere stromingen en diepgang.
30-01-2017, 08:23 door
[Account Verwijderd]
[Verwijderd]
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?