Ik weet er wel een stel, maar dit klinkt als een vraag van een student die een (afstudeer-) verslag moet schrijven. Van copy/pasten leer je echter weinig tot niets. Begin eens met het lijstje dat je zelf al hebt bedacht?

@Erik ik ben geen student en ik heb zelf ook wel een aantal punten bedankt, zoals:
* Software moet van website leverancier komen
* Is software gesigneerd
* Welke connecties maakt de software.
* Afhankelijkheden
* Rechten die software nodig heeft

Ik heb echter geprobeerd om de vraag zo open mogelijk te stellen, zodat ik het antwoord voor anderen niet alvast ga invullen.
Als je nog aanvullingen hebt, graag.

Toppie, als iedereen informatie deelt profiteert iedereen!

Dat laatste vind ik zelf belangrijker dan dat de software van "de website van de leverancier" komt. Want:
- hoe stel je vast of de website van een leverancier is en deze niet is gecompromitteerd
- veel software met een klein of geen verdienmodel wordt vaak via meerdere sites van derden gedistribueerd

Hou er rekening mee dat vooral software met een kwaadaardige component zich anders kan gedragen vooral indien geen sprake is van virtualisatie, en/of afhankelijk van allerlei lokale omstandigheden. Test dus op een fysiek werkstation met een realistische setup.

Upload de software ook naar bijv. www.virustotal.com (als je de binary zelf niet wilt uploaden, hun je er ook een hash van maken en die opzoeken op Virustotal, grote kans dat iemand anders al gescand heeft). Hoe ouder de eerste scan van die software en hoe minder narigheid erover bekend is, hoe betrouwbaarder de maker.

Een afhankelijkheid van Java is niet moeilijk vast te stellen, tenzij Java stilletjes wordt geinstalleerd. Welke versie wordt dan op je systeem gezet? Zoek na installatie naar files als "libeay*.dll", "ssleay*.dll", "openssl*.*" en, indien aanwezig, kijk welke versie dat is en probeer vast te stellen waar dit soort security-sensitive files voor worden gebruikt. Het kan ook zijn dat software de beschikbaarheid van de MSIE engine vereist. Afhankelijkheid van Adobe Flash lijkt me onwenselijk.

Zeker. Check niet alleen de submap onder "Program Files" en "Program Files (x86)" , maar ook evt. submappen onder "ProgramData" en, niet te vergeten, het register. Kijk ook of de software nieuwe accounts heeft aangemaakt.

Zomaar wat zaken uit de losse pols die ik ook zou checken (afhankelijk van de hoeveelheid tijd die ik heb en de verwachte risico's):
- Hoe luiden de privacy voorwaarden
- Hoe groot is het risico op vendor lock-in
- Hoe groot is het risico op overname van de leverancier, of discontinuïteit op andere wijze
- Bij een contract: wat is de exit procedure? Met name als er data in de cloud staat: van wie is die data?
- Hoe heeft de leverancier zich in het verleden gedragen
- Update de software zichzelf, kan een gebruiker dat initiëren of krijgt deze een suffe popup met de vraag een admin wachtwoord in te voeren
- Hoe veilig is het updateproces (wel geen https connectie, signed files ja/nee, worden certs daadwerkelijk gecheckt)
- Overschrijft het installatieproces systeemfiles
- Probeert het installatieproces andere software te verwijderen of te wijzigen
- Hoe zijn de beheermogelijkheden; kun je bijv. met policies restricties aanbrengen (voor zover je dat wilt)

En nu ga ik weer verder met m'n werk. Mocht ik nog andere zinvolle zaken bedenken, dan post ik die misschien later nog wel.

Ja dat met die rechten is belangrijk.
Software moet draaien onder een normaal user account.
UAC popup (wants to use Administrator rights) -> exit
Geen schrijfrechten nodig binnen de installatie directory na installatie en evt initiele configuratie door de administrator
Geen dynamische downloads van allerlei "plugin" of andere executable troep bij start door de gebruiker.
(bijvoorbeeld GoToMeeting is dat soort rotzooi)

Nouja, het is hetzelfde probleem in een ander jasje. "Ga ik naar zijn huis of kijk ik naar zijn handtekening?" Waarbij een website-met-eigen-domein slechts indirect "je huis" is en een certificaat uitgegeven wordt uitgegeven door een derde die je ook maar moet vertrouwen, dus in feite ook indirect is. En zelfs de secuurste uitgever maakt ook wel eens fouten.

Want wie kijkt er nou de hele keten na? De software is bovendien zo slecht dat het effectief zegt "kijkma nie na, da's toch veuls te moeluk foor jou jonguh". Tsja, als je het zo stelt.

Daarnaast ben ik een beetje moe geworden van al die techneuten die "signeren! signeren!" roepen zoals ze ook "2FA! 2FA!" roepen, of dat nou nuttig is of niet. Voor je het weet komt er een partij om de hoek kijken die met een "oplossing" komt, verkocht als "voor de veiligheid", maar uiteindelijk vooral jou macht en mogelijkheden ontneemt.

Wat niet weg neemt dat bijvoorbeeld een GPG-signatuur best een goed^Wredelijk idee is, maar correct gebruik zie je (nog) maar heel zelden. En als je dan als bedrijf je leveranciers gaat pesten met je eisenlijstjes krijg je van dat plichtmatige gedoe waar verder inhoudelijk niet over nagedacht wordt, waarmee je uiteindelijk alleen de schijn van veiligheid als een dekentje over je heentrekt, maar geen werkelijke veiligheidgaranties toevoegd. Het kan zelfs hard misgaan, bijvoorbeeld omdat wel een sleutel voor signeren geregeld is maar het sleutelbeheer even vergeten, en toen lekte onbedoeld en ongemerkt de sleutel naar kwaadwillenden. (Dit is inderdaad een praktijkvoorbeeld.)

Daar begint het gedonder inderdaad al mee. Voor je het weet zit er adware tussen. *kuch* sourceforce *kuch*

Het is dus wel belangrijk zoveel mogelijk uit te pluizen en helder te maken wie je nou eigenlijk waarvoor vertrouwt, maar dat doe je niet met wat platte regeltjes. Teken het hele plaatje uit, inclusief verkoopkanalen, payment processors, maar ook dynamische en statische programmabibliotheken, zelfs de software gebruikt om de software te bouwen. En dan zie je al snel dat het hele feest ontploft en het toch wel een boel werk wordt. Tsja, wat doe je daar nou weer aan? Maar dat is wel een fundamenteel probleem met het moderne computergebruik: Het is zo complex dat de boel uitpluizen om te begrijpen wat er nou eigenlijk gaande is al heel snel ondoenlijk gaat lijken.

Dit is wel een voordeel van open source: Je kan veel beter zien waar het verder zoal nog op leunt. De ontwikkelhistorie is vaak zelfs compleet te vinden. (Vraag dat maar eens aan een willekeurige grote software leverancier.) Een nadeel is dat stukjes broncode ineens overal vandaan kunnen komen en dat uitzoeken nog steeds een klerewerk is.


En adminrechten. Als onnodig vereist, weg met het programma.

Eigenlijk best wel typisch dat zo'n "enterprise"-besturingssysteem het zo ingewikkeld maakt om dit soort dingen op te snorren.

Wellicht kan je hier nog wat inspiratie uit halen?
http://www.k-state.edu/its/software/pdfs/software-acquisition-checklist.pdf

gr. BB