Kennisplatform

Mijn oog viel op deze tweet van de Engelse toezichthouder, waar ik een tikje van opkeek:

“Hi, orgs should not look to adopt a blanket approach in asking for ID when responding to a SAR [inzageverzoek onder de AVG]. They should consider each request on a case by case basis and identify which form of ID is most proportionate if required.”

De tweet was een reactie op een vraag van de onvolprezen privacyvoorvechter Pat Walshe, die constateerde dat je bij het vragen van een kopie van je persoonsgegevens bij Engelse politieke partijen altijd een kopie ID moet meesturen. Uit de reactie valt op te maken dat dat niet mag, en dat een organisatie dus per verzoek moet kijken of de persoon duidelijk geïdentificeerd is als de betrokkene en zo nee wat in dat geval het handigste is.

As a defender, looking at events occurring at user endpoints is very useful. It's essential to know exactly what is happening and insight in detailed log information gives you the opportunity to perform threat hunting and to create detection rules.

It’s a no-brainer that looking at processes on an user endpoint is crucial in order to find adversary’s activities. One of the interesting aspects of the process is the access token. In this blog I will explain briefly what an access token is and how you can use Microsoft Defender ATP (MDATP) and the Kusto query language to examine them in detail.

Een bekende valkuil voor gemeenten is dat de omgang met persoonsgegevens wordt aangevlogen via de juridische route, oftewel: “Dat mag (niet) van de AVG”. Er wordt strikt gekeken aan welke minimale wettelijke vereisten dient te worden voldaan. Op deze wijze wordt het nagenoeg onmogelijk om privacy in het DNA van de organisatie te krijgen. Het blijft immers wéér zo’n wet die in de weg staat van het werk. Terwijl gemeenten juist de kans hebben om trots te handelen vanuit de bedoeling van de AVG: optimale, gebruiksvriendelijke dienstverlening bieden waarbij de burger, mede door een transparante houding van gemeenten, kan vertrouwen op een zorgvuldige omgang met persoonsgegevens.

All kinds of online services get hacked. This includes services that you might be using. Scattered Secrets is a password breach notification and prevention service. We continuously collect publicly available hacked databases and try to crack the corresponding passwords. Verified account owners can access their own information and take appropriate action to keep their accounts safe and prevent against account takeovers. At the time of writing, our database includes nearly four billion — yes, that is with a B — plaintext passwords. Users occasionally ask us how we can crack passwords on such a large scale. To answer this, first we need to look at the basics.

Stel er wordt een creditcard op je naam aangevraagd en gebruikt, hoe bewijs je dan dat jij dat niet was? Met die vraag zag een man in Noord-Holland zich onlangs geconfronteerd, toen hij werd gedagvaard door American Express wegens het niet voldoen van de schuld die op die kaart was opgebouwd. De kaart was via internet afgenomen op zijn naam, en ook was er een betalingspatroon dat consistent leek met het gedrag van de man. AmEx vond dat het daarom duidelijk was dat hij die kaart had afgenomen. De rechter kijkt er nog eens kritisch naar en komt tot een andere conclusie.

In this day and age having a functioning and secure Software Development Life Cycle (SDLC) process in place is becoming a key component of a successful organization. And one methodology that is becoming increasingly popular is DevOps. Mainly, because the methodology itself is designed to produce fast and robust software development. In this article, we will focus on how we can incorporate security into CI/CD and turning DevOps into DevSecOps easily and with automation in mind.

It’s quite a long article, so in case you are already familiar with some of the terms, feel free to skip to whatever part pleases your curiosity :)

This post concerns application security teams, so it’s written assuming you are part of one. However, I believe it could help you understand application security a bit more even if you are not.

If you are part of an application security team, you probably struggle with the amount of work on your shoulders every day. Let’s say you have a small team of 5 people to test all web applications produced by a group of 200 developers, and you still need to provide guidance on how to fix some vulnerabilities. You try to offload some work by handing developers with security testing tools, but the learning curve is long - causing frustration. Basically, you have a scaling issue!

De kogel lijkt door de kerk, idensys is niet meer en de overheid heeft na een lange tijd van bezinning gekozen voor een betere manier om mensen toegang te verlenen tot overheidssites. Naast DigiD gaat de overheid ook andere leveranciers van inlogfaciliteiten toelaten.

Ik ben hier heel blij mee, want deze koersverandering is volkomen in lijn met wat ik in mijn vorige digidem blog schreef:

“Zie je dan een alternatief voor Idensys? Ja natuurlijk, plenty:
Federeren maar… Laat de overheid gewoon vanaf nu de bank-identiteiten accepteren om mee in te loggen en meteen ook maar een stel andere providers, zoals Facebook en Twitter. Prima, lekker makkelijk en heel snel te regelen.”

Jira is one of the most widely adopted Issue and Project Tracking Software out there. Atlassian’s Jira has been named the #1 software development tool for agile teams. And Probely now allows you to synchronize your security issues into your Jira issue tracker. So, how do you manage vulnerabilities in Jira using Probely?

Multidisciplinary Aspects of Blockchain is a different book on a fundamental digital technology under development and published in Dutch (hardcopy) and English (eBook) as part of a series of the Royal Dutch Society for Computer and Information Professionals. Blockchain, which reportedly changes society as the ultimate disruptor and most important invention after the introduction of the World Wide Web of Internet. Blockchain is a collective term for digital databases, which are distributed, mathematically-protected and chronological in nature.

“I rob banks because that is where the money is”, is a famous quote attributed to (in)famous bank robber Willie Sutton[1]. It is also known as Sutton’s Law. Suttons law still holds true for many things, including modern (cyber)crime. If you want to earn money from your crimes, focus on what people value most.

Ransomware is an example of just this. Criminals target what is most valuable to organisations and individuals, their data or memories.

Wanneer uw bedrijf (organisatie) wordt getroffen door een ernstig incident wat de bedrijfsvoering verstoort, oftewel (bepaalde) activiteiten kunnen niet meer worden uitgevoerd, dan implementeert u het plan B, het bedrijfscontinuïteitsplan (Business Continuity Plan – BCP). Iedereen pakt zijn of haar taken op om de geprioriteerde, kritische activiteiten te herstellen om ‘Wat wij hier doen’ zo optimaal mogelijk voort te zetten. Een fantastisch streven, dat moet gezegd worden. Echter in alle situaties dient dat tezamen met anderen uitgevoerd te worden en niet in isolement.

Data leaks have become an all-too-common societal problem. Still, 99% of the problems do not involve scary zero-day bugs. So why is security still hard? We need to accept that technology isn’t going to save us. Rather, thinking it can, got us in this situation in the first place. We need a new way of teaching and implementing security across our organizations. I am introducing the AVA=Risk Security Model to help us get there.

Volgens een artikel in de Volkskrant zou Huawei mogelijk betrokken zijn bij spionage op een Nederlandse telecomprovider. Het gepresenteerde bewijs en de interpretatie ervan zijn in mijn ogen mager. Er is overigens wel reden om aan Huawei te twijfelen.

Huawei zou betrokken zijn bij de hack op een in Nederland opererende telecomprovider. Via een achterdeur zijn klantgegevens gestolen en dat is volgens de definitie computervredebreuk of simpel gezegd: hacking. De AIVD zou onderzoek doen. De krant baseert zich op inlichtingenbronnen. Over het journalistieke proces is niets bekend gemaakt.

Risk Management (RM) of Risicobeheer c.q. de ingeburgerde vertaling Risicomanagement, wordt op vele manieren gedefinieerd, maar is in dit verband het best te omschrijven als ‘Activiteiten en methoden die worden gebruikt om risico's te beheersen die het vermogen om doelstellingen te bereiken kunnen beïnvloeden’. Een risico is vervolgens in dit kader ‘Het effect van onzekerheid op het behalen van doelstellingen’. Business Continuity Management (BCM) of in goed Nederlands Bedrijfscontinuïteitsbeheer, gaat over het beschermen van uw organisatie tegen de gevolgen van omvangrijke verstoringen en (on)bekende risico’s op uw vermogen om producten en diensten te kunnen leveren aan uw afnemers. Op dit ‘Platform voor organisatieontwikkeling’ is hier al meerdere malen uitgebreid aandacht aan besteed. Wat is het verschil tussen beiden en wat is de samenhang?