Bijna tweeduizend Exchange-servers besmet via ProxyShell-lekken
Bijna tweeduizend Microsoft Exchange-servers zijn de afgelopen dagen besmet via drie kwetsbaarheden die bekendstaan als "ProxyShell". Door de drie beveiligingslekken te combineren is het mogelijk voor ongeauthenticeerde aanvallers om kwetsbare Exchange-servers op afstand over te nemen. Deze servers worden onder andere met ransomware geïnfecteerd. De Amerikaanse overheid roept organisaties op om snel in actie te komen.
Microsoft kwam in april en mei met beveiligingsupdates voor de kwetsbaarheden, aangeduid als CVE-2021-34473, CVE-2021-34523 en CVE-2021-31207. Orange Tsai, de onderzoeker die de beveiligingslekken ontdekte, gaf begin deze maand tijdens de Black Hat- en Defcon-conferenties een presentatie waarin hij technische details over de kwetsbaarheden besprak. Aan de hand van deze informatie konden exploits worden gepubliceerd, die vervolgens tegen kwetsbare Exchange-servers werden ingezet.
Het Internet Storm Center meldde recentelijk op basis van een scan van zoekmachine Shodan dat er nog meer dan 30.000 ongepatchte Exchange-servers op internet waren te vinden. De afgelopen dagen is er een toename van het aantal aanvallen op deze machines. Zo meldde securitybedrijf Huntress Labs dat het meer dan honderdveertig verschillende webshells op bijna tweeduizend ongepatchte Exchange-servers heeft aangetroffen. Een webshell is een script dat aanvallers op servers plaatsen om toegang te behouden en op afstand code en commando's uit te voeren.
Beveiligingsonderzoeker Kevin Beaumont laat weten dat er een groep aanvallers is die de kwetsbaarheden gebruiken om Exchange-servers met ransomware te infecteren, genaamd LockFile. Deze ransomware versleutelt bestanden voor losgeld. Vanwege de toegenomen aanvallen roept het Cybersecurity and Infrastructure Security Agency (CISA) van het Amerikaanse ministerie van Homeland Security organisaties op om met spoed kwetsbare Exchange-servers binnen het eigen netwerk te identificeren en de beveiligingsupdates van Microsoft te installeren.
Reacties (23)
22-08-2021, 09:40 door
karma4
Het is bekend kip-ei verhaal met een https 443 benadering. Web access met het stateless zijn en onduidelijke herkomst zal poblemen blijven geven. Met deze https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
Kerberos (MITT) geeft ook zijn uitdagingen en valkuilen (zie link in artikel) In het verlengde hiervan kun je ernstig twijfelen aan de keys-certificate oplossingen.
Kerberos (MITT) geeft ook zijn uitdagingen en valkuilen (zie link in artikel) In het verlengde hiervan kun je ernstig twijfelen aan de keys-certificate oplossingen.
"Het Internet Storm Center meldde recentelijk op basis van een scan van zoekmachine Shodan dat er nog meer dan 30.000 ongepatchte Exchange-servers op internet waren te vinden. "
als nu deze excange servers elke dag automatisch kwalitatieve updates zouden krijgen zonder dat er dingen stuk zouden gaan en er steeds reboots nodig waren, dan was dit geen issue meer geweest!
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
als nu deze excange servers elke dag automatisch kwalitatieve updates zouden krijgen zonder dat er dingen stuk zouden gaan en er steeds reboots nodig waren, dan was dit geen issue meer geweest!
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
Door karma4: Het is bekend kip-ei verhaal met een https 443 benadering. Web access met het stateless zijn en onduidelijke herkomst zal poblemen blijven geven. Met deze https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
Kerberos (MITT) geeft ook zijn uitdagingen en valkuilen (zie link in artikel) In het verlengde hiervan kun je ernstig twijfelen aan de keys-certificate oplossingen.
Volgens mij is de GPT3 bot vastgelopen.Kerberos (MITT) geeft ook zijn uitdagingen en valkuilen (zie link in artikel) In het verlengde hiervan kun je ernstig twijfelen aan de keys-certificate oplossingen.
Wat ik zo raar vind is dat Microsoft de gebruikers die hun mail inmiddels naar hun cloud omgeving gemigreerd hebben
en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Goed om te weten waar je SSL sleutels zijn en zorgen dat niemand er bij kan, anders is je domein jouw domein niet langer. Comodo en de niet langer vertrouwde Symantec keys in Chrome en Firefox.
Cheap SSL.keys come with a price.
luntrus
Cheap SSL.keys come with a price.
luntrus
Het veranderen van sleutels bij het vernieuwen van een certificaat wordt veel gedaan, maar is geen best policy. Laat sleutelbeheer over aan een doorgewinterd iemand, a seasoned person.
luntrus
luntrus
22-08-2021, 13:48 door
karma4
Door Anoniem: ....
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
Ik zag weinig server side problemen in het verhaal masr wel een reeks aan open source protocol problematiek.
Https webserverers cookies, totdat je met de rechten van het serverproces als root/system verder kan.
Op dat moment is laterale beweging de bedoeling want gewoonlijk zijn clusters daarvoor open gezet (netwerk segmentatie ontbreekt). Dit soort proematiek is vrij gangbasr juist ook in de lamp stack.
Gewoonlijk is sqlinjection de topper in gemaakte fouten in de reeks van code injection.
Door karma4:
Ik zag weinig server side problemen in het verhaal masr wel een reeks aan open source protocol problematiek...
Door Anoniem: ....
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
kun je ook verder zwammen over het https protocol wat je wilt... de oorsprong is duidelijk een brakke serverside implementatie. er zijn web mail interface implementaties die die issues niet hebben! ook zijn er omgevingen waarbij de server processen niet als admin/root draaien en het een heel stuk lastiger maken een web shell te droppen!
Ik zag weinig server side problemen in het verhaal masr wel een reeks aan open source protocol problematiek...
Een 'open source' protocol? Zijn de broncodes van de Microsoft protocol implementatie in Exchange dan als open source beschikbaar in bv. GitHub? Nee, eigenlijk niet hè... Je verwart duidelijk open standaard met open source. Een open standaard kan je met closed source implementeren, Microsoft doet niet anders. En natuurlijk is dat ook weer zo'n spaghetticodebouwwerk met allerlei problemen. En daar gaat dit topic ook over.
22-08-2021, 17:23 door
karma4
Door Toje Fos: Een 'open source' protocol? Zijn de broncodes van de Microsoft protocol implementatie in Exchange dan als open source beschikbaar in bv. GitHub? Nee, eigenlijk niet hè... Je verwart duidelijk open standaard met open source. Een open standaard kan je met closed source implementeren, Microsoft doet niet anders. En natuurlijk is dat ook weer zo'n spaghetticodebouwwerk met allerlei problemen. En daar gaat dit topic ook over.
Je verwart duidelijk de spaghetti doe vanzlef mettertijd in open protocollen ontstaat met de daaraan verbonden risico's met je merkbinding / merkhaat. Een vendor lockin of vendor lockout komt feitelijk op een lockin neer.
Je zou je wat meer in het veld van de open standaarden moeten verdiepen https://www.w3.org/Security/ juist met het oog op security. Je hebt duidelijk het verhaal artikel niet gelezen en de video niet bekeken. zo wort het nooit wat met een goede beveiliging. Dezelfde aanpak om sleutels te bypassen kun je voor veel meer zaken bedenken.
en hier de slides vwb proxyshell:
https://media.defcon.org/DEF%20CON%2029/DEF%20CON%2029%20presentations/Orange%20Tsai%20-%20ProxyLogon%20is%20Just%20the%20Tip%20of%20the%20Iceberg%2C%20A%20New%20Attack%20Surface%20on%20Microsoft%20Exchange%20Server.pdf
heeft helemaal niets met http/https of protocollen te maken. al helemaal niets met open source.
deze is trouwens ook leuk:
https://media.defcon.org/DEF%20CON%2029/DEF%20CON%2029%20presentations/Tianze%20Ding%20-%20Vulnerability%20Exchange%20-%20One%20Domain%20Account%20For%20More%20Than%20Exchange%20Server%20RCE.pdf
laat slide 35 eens op je inwerken. lees dan door en laat dan slie 49 op je inwerken!
gatenkaas dat spul!
https://media.defcon.org/DEF%20CON%2029/DEF%20CON%2029%20presentations/Orange%20Tsai%20-%20ProxyLogon%20is%20Just%20the%20Tip%20of%20the%20Iceberg%2C%20A%20New%20Attack%20Surface%20on%20Microsoft%20Exchange%20Server.pdf
heeft helemaal niets met http/https of protocollen te maken. al helemaal niets met open source.
deze is trouwens ook leuk:
https://media.defcon.org/DEF%20CON%2029/DEF%20CON%2029%20presentations/Tianze%20Ding%20-%20Vulnerability%20Exchange%20-%20One%20Domain%20Account%20For%20More%20Than%20Exchange%20Server%20RCE.pdf
laat slide 35 eens op je inwerken. lees dan door en laat dan slie 49 op je inwerken!
gatenkaas dat spul!
Door karma4:
Je verwart duidelijk de spaghetti doe vanzlef mettertijd in open protocollen ontstaat met de daaraan verbonden risico's met je merkbinding / merkhaat. Een vendor lockin of vendor lockout komt feitelijk op een lockin neer.
Door Toje Fos: Een 'open source' protocol? Zijn de broncodes van de Microsoft protocol implementatie in Exchange dan als open source beschikbaar in bv. GitHub? Nee, eigenlijk niet hè... Je verwart duidelijk open standaard met open source. Een open standaard kan je met closed source implementeren, Microsoft doet niet anders. En natuurlijk is dat ook weer zo'n spaghetticodebouwwerk met allerlei problemen. En daar gaat dit topic ook over.
Je verwart duidelijk de spaghetti doe vanzlef mettertijd in open protocollen ontstaat met de daaraan verbonden risico's met je merkbinding / merkhaat. Een vendor lockin of vendor lockout komt feitelijk op een lockin neer.
Iemand die weet wat hier staat en wat er bedoeld wordt in de context van mijn reactie? Ik kan er geen kaas van maken...
Door karma4: Je zou je wat meer in het veld van de open standaarden moeten verdiepen https://www.w3.org/Security/ juist met het oog op security. Je hebt duidelijk het verhaal artikel niet gelezen en de video niet bekeken. zo wort het nooit wat met een goede beveiliging. Dezelfde aanpak om sleutels te bypassen kun je voor veel meer zaken bedenken.
Open standaarden zijn het probleem niet. Die zijn prima. Closed source spaghetticodebouwwerk implementaties van al dan niet open standaarden zijn dat wel.
Gevonden SPF record v = spf1 Mx include ~all
Bevat dus een ~all item geen DMARC record
Conclusie spoofing is mogelijk.
luntrus
Bevat dus een ~all item geen DMARC record
Conclusie spoofing is mogelijk.
luntrus
https://www.thurrott.com/windows/windows-10/187407/microsoft-has-a-software-quality-problem
Artikel uit 2018 maar actueler dan ooit (sterker nog, het wordt eigenlijk alleen maar actueler, want een kenmerk van spaghetticode is dat het niet meer te redden valt). #nofurthercomment
Artikel uit 2018 maar actueler dan ooit (sterker nog, het wordt eigenlijk alleen maar actueler, want een kenmerk van spaghetticode is dat het niet meer te redden valt). #nofurthercomment
@Toje Fos,
In deze met je eens. Mede oorzaak security through obscurity propriety code. Trekken aan een lang overleden MS dos paard.
Men laat velen geloven dat het deugdelijk kan blijven. Maar ja dat komt wel meer voor met/bij wat globalisten in de markt zetten. Toch blijft een gedeelte der mensheid erbij zweren.
In deze met je eens. Mede oorzaak security through obscurity propriety code. Trekken aan een lang overleden MS dos paard.
Men laat velen geloven dat het deugdelijk kan blijven. Maar ja dat komt wel meer voor met/bij wat globalisten in de markt zetten. Toch blijft een gedeelte der mensheid erbij zweren.
Door Anoniem: Wat ik zo raar vind is dat Microsoft de gebruikers die hun mail inmiddels naar hun cloud omgeving gemigreerd hebben
en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
je hebt geen volwaardige Exchange server nodig, enkel de beheertools. Je kan alles m.b.t. mailflow, webmail etc uitschakelen het heeft voornamelijk te maken met het aanmaken/beheren van mailbox en ervoor zorgen dat de objecten in AD terecht komen. In een hybride omgeving is on-premise leading en dient het beheer dus ook daar plaats te vinden.en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Je kan het trouwens ook zonder Exchange server doen echter is het dan geen "supported" omgeving en zul je met ADSI-edit of andere tooltjes aan de gang moeten
Door Anoniem:
Maar die server moet wel vanaf internet te connecten zijn! Want de cloud omgeving connect de server, ipv omgekeerdDoor Anoniem: Wat ik zo raar vind is dat Microsoft de gebruikers die hun mail inmiddels naar hun cloud omgeving gemigreerd hebben
en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
je hebt geen volwaardige Exchange server nodig, enkel de beheertools. Je kan alles m.b.t. mailflow, webmail etc uitschakelen het heeft voornamelijk te maken met het aanmaken/beheren van mailbox en ervoor zorgen dat de objecten in AD terecht komen. In een hybride omgeving is on-premise leading en dient het beheer dus ook daar plaats te vinden.en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
zoals het zou moeten zijn. Dus je moet je poort 443 gewoon open hebben staan anders gaat het niet werken.
Waarom fixen ze dat niet??? Omdat het ze niet interesseert. Zit geen geldverdienmodel aan vast.
Door Anoniem:
zoals het zou moeten zijn. Dus je moet je poort 443 gewoon open hebben staan anders gaat het niet werken.
Waarom fixen ze dat niet??? Omdat het ze niet interesseert. Zit geen geldverdienmodel aan vast.
Door Anoniem:
Maar die server moet wel vanaf internet te connecten zijn! Want de cloud omgeving connect de server, ipv omgekeerdDoor Anoniem: Wat ik zo raar vind is dat Microsoft de gebruikers die hun mail inmiddels naar hun cloud omgeving gemigreerd hebben
en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
je hebt geen volwaardige Exchange server nodig, enkel de beheertools. Je kan alles m.b.t. mailflow, webmail etc uitschakelen het heeft voornamelijk te maken met het aanmaken/beheren van mailbox en ervoor zorgen dat de objecten in AD terecht komen. In een hybride omgeving is on-premise leading en dient het beheer dus ook daar plaats te vinden.en die nog een Exchange server moeten draaien als "hybrid" server voor hun klassieke omgeving, maar waar die server
dus nooit meer connecties vanaf internet zou hoeven accepteren, niet helpt door het protocol tussen hybrid en cloud
om te keren. Nu moet je hybrid server inkomende connecties "van Microsoft" accepteren, en dat is een idioot lange
lijst met subnetten waar vast ook klanten in gehuisvest zijn. Waarom keren ze dat niet om en laten de hybrid server
een permanente https connectie met de cloud open houden voor dat verkeer? Dan kunnen klanten de firewall dicht zetten.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
zoals het zou moeten zijn. Dus je moet je poort 443 gewoon open hebben staan anders gaat het niet werken.
Waarom fixen ze dat niet??? Omdat het ze niet interesseert. Zit geen geldverdienmodel aan vast.
Wat je zegt klopt niet. Het hoeft niet via internet bereikbaar te zijn, daarnaast verzorgt een on-premise applicatie (Azure AD Connect, dus niet Exchange) de synchronisatie met de cloud.
@ anoniem van 11:04
Wel even dit checken in dat geval:
https://sysmanrec.com/powershell-script-to-check-if-azure-ad-connect-is-affected-by-the-vulnerability-described-in-cve-2021-36949
luntrus
Wel even dit checken in dat geval:
https://sysmanrec.com/powershell-script-to-check-if-azure-ad-connect-is-affected-by-the-vulnerability-described-in-cve-2021-36949
luntrus
23-08-2021, 20:44 door
karma4
Door Toje Fos: ......Open standaarden zijn het probleem niet. Die zijn prima. Closed source spaghetticodebouwwerk implementaties van al dan niet open standaarden zijn dat wel.
Je mist duidelijk de kern van het probleem en zit de gatenkaas onder je ogen niet (open source protocollen)Dan zal het ook nooit wat worden met een een echt veilige omgeving, ziet IOT/
23-08-2021, 23:03 door
walmare
Door karma4:
Dan zal het ook nooit wat worden met een een echt veilige omgeving, ziet IOT/
Hij weet waar hij het over heeft. JIj niet met je open source protocollen. Jij bent alleen maar open source aan het bashen. Door Toje Fos: ......Open standaarden zijn het probleem niet. Die zijn prima. Closed source spaghetticodebouwwerk implementaties van al dan niet open standaarden zijn dat wel.
Je mist duidelijk de kern van het probleem en zit de gatenkaas onder je ogen niet (open source protocollen)Dan zal het ook nooit wat worden met een een echt veilige omgeving, ziet IOT/
Het gaat hier over een zeer ernstig Microsoft Exchange gesloten software probleem.
We zijn hier nog niet klaar mee. Het Exchange security fiasco blijft nog wel een tijdje doorgaan. Samen met de printer spooler een blok aan het been van veel enterprises. Dat had je vast wel begrepen, maar je moest je even afreageren door dat verdomde open source succes wat hier tegenover staat.
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Wist je dat dan nog niet? Zoveel resources tot hun beschikking en dan zulke rommel leveren. Als ze klantbelangen voorop hebben staan, hadden zie de miljarden in kas wel aangewend om een fatsoenlijk product in de markt te zetten.
Door Anoniem:
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Wist je dat dan nog niet? Zoveel resources tot hun beschikking en dan zulke rommel leveren. Als ze klantbelangen voorop hebben staan, hadden zie de miljarden in kas wel aangewend om een fatsoenlijk product in de markt te zetten.
Dat is het bekende probleem van een monopolie. Bijna Iedereen is naar exchange gemigreerd tegen beter weten in. Waarom?Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Wist je dat dan nog niet? Zoveel resources tot hun beschikking en dan zulke rommel leveren. Als ze klantbelangen voorop hebben staan, hadden zie de miljarden in kas wel aangewend om een fatsoenlijk product in de markt te zetten.
Door Anoniem:
lemmingengedrag
Door Anoniem:
Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Wist je dat dan nog niet? Zoveel resources tot hun beschikking en dan zulke rommel leveren. Als ze klantbelangen voorop hebben staan, hadden zie de miljarden in kas wel aangewend om een fatsoenlijk product in de markt te zetten.
Dat is het bekende probleem van een monopolie. Bijna Iedereen is naar exchange gemigreerd tegen beter weten in. Waarom?Of is het wellicht zo dat Microsoft zich niet interesseert voor klanten??
Wist je dat dan nog niet? Zoveel resources tot hun beschikking en dan zulke rommel leveren. Als ze klantbelangen voorop hebben staan, hadden zie de miljarden in kas wel aangewend om een fatsoenlijk product in de markt te zetten.
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?