Wat ik mis is de onderbouwing dat het om de intentie ging om user-passwords van anderen als informatie te stelen.
I wat voor log-file dan ook zul je keystroke/invoer logging als verplichte audit-trail tegenkomen. Wie heeft wat veranderd en waarom is zo'n verplicht audit gegeven..

Gaan zo ook fabrikanten de koevoet bestraffen, deze worden ook vaak gebruikt bij een inbraak ?

Meer achtergrond info :
https://motherboard.vice.com/read/student-hacker-faces-10-years-in-prison-for-spyware-that-hit-16000-computers

Er zijn producten en diensten waarvan je kan weten dat 99% goed zal worden ingezet en 1% kwaad. Net als er producten en diensten zijn waarvan je kan weten dat de kans enorm groot is dat het niet legaal zal worden ingezet. Ik ken de wetten van de USA niet maar gewoonlijk is het niet legaal om derden te bespioneren. En voor een goede audit trail ga je geen studentenforum gebruiken en laten betalen met bitcoins maar zorg je juist voor een goede onderbouwing. je wil immers ook niet dat de software iets meer doet dan voor een audit noodzakelijk is en anders juridisch succesvol bij de verkoper kunnen aankloppen. En waarschijnlijk zal een rechter ook zijn vraagtekens hebben of de verkoper er geen moment bij stil gestaan heeft dat verkoop aan 3000 klanten zonder daar echt van te weten wie het zijn en wat hun intenties zijn genoeg is om te beweren dat het allemaal legaal zou worden ingezet. Ik hou me van de domme is geen goed uitgangspunt als je er voor kiest om in een schimmige omgeving geld aan het verdienen bent met spyware.

Vergelijk je het nu met keyloggers die worden aangeboden om werknemers in de gaten te houden waarbij de makers graag met termen als "audit trail" smijten? Die zijn (in ieder geval in delen van) de VS legaal, maar daarmee zijn ze nog niet verplicht. Keystroke logging als verplichte audit-trail aanmerken slaat nergens op. Er zijn natuurlijk verplichte audit trails, maar je smijt die in je zin op een hoop met keyloggers, en die vallen niet onder die verplichting.

Een audit trail heeft een duidelijk doel: handelingen terug kunnen voeren op een bron. Een bank legt bij alle binnenkomende opdrachten bijvoorbeeld de originele opdracht, zoals die van buiten is aangeleverd, vast, bewaart hem, en neemt een referentie eraan op in de opdracht die in de verdere verwerking wordt aangevuld, mogelijk gecorrigeerd, gesplitst naar opdrachten voor deelsystemen (zo ingewikkeld kan het worden, bijvoorbeeld bij effectenopdrachten waar geld en aandelen mee gemoeid zijn), zodat alle verschijningsvormen altijd naast het origineel kunnen worden gehouden. Die originele vorm is een record met gegevensvelden. Die wordt vaak elektronisch aangeleverd door informatiesystemen van anderen zodat een keylogger volslagen zinloos is voor dat doel.

Softwareontwikkelaars hebben ook een audit trail in hun versiebeheersoftware. Daar worden versies van broncode, het verband met de versies waar ze op gebaseerd zijn, de reden van de wijziging, en welke programmeur hem op welk moment heeft ingebracht vastgelegd. Verschillende mensen kunnen parallel aan dezelfde source werken, wat versies oplevert die weer samengevoegd moeten worden. De geschiedenis van software is daardoor vaak niet lineair maar heeft een netwerkstructuur. Omdat een log (synoniem: journaal, een chronologische vastlegging) lineair is is een software-repository per definitie geen log. En toch bevat het een gedetailleerde audit-trail. Een audit-trail kan zonder log-files bestaan. En ook hier is het onzinnig om elke toetsaanslag te bewaren. Te veel detail zou het onoverzichtelijk maken, je hoeft niet meer te weten dan wie wanneer en waarom welke brokken code heeft aangeleverd in versies die daadwerkelijk produktie gaan draaien.

En natuurlijk bevatten lang niet alle log-files gebruikersinvoer, zoals je lijkt te denken ("I[n] wat voor log-file dan ook"). Diverse systeem-logbestanden documenteren het functioneren van het systeem of services die erop draaien, niet zo zeer het doen en laten van gebruikers.

Het is dus maar zeer de vraag of een keylogger wel zo'n geschikt instrument voor audit trails is. Voor veel toepassingen is het veel te breed én tegelijk onvolledig. Als het doel is om personeelsleden even gedetailleerd als ongericht in de gaten te houden, ja, dan ga je mogelijk dat soort dingen inzetten, maar los van inzet bij concrete fraudeverdenkingen tegen specifieke personen zie ik dat vooral als het niet inzetten van middelen die ellende kunnen voorkomen en dat niet oplossen maar opvangen met meer ellende.

Je mist onderbouwing van de intentie, maar het bericht zegt dat de keylogger "wachtwoorden en gegevens voor internetbankieren verzamelde". "Voor internetbankieren" suggereert dat de tool selectief weet te loggen, en als dat voor legitieme doeleinden is is het erg vreemd dat wachtwoorden daarbij niet netjes worden overgeslagen. Het feit dat iemand daarvoor vervolgd wordt is een vette hint. Dat de onderbouwing verder niet is uitgewerkt, ook niet in het gelinkte persbericht van justitie, heeft vermoedelijk te maken met het feit dat het niet de aanklacht zelf is maar een persbericht erover. We krijgen vast nog wel te horen hoe de rechter het beoordeelt.

Thnks Anoniem 15:41 Hoewel dat artikel
niet compleet vrij van veronderstellingen is, is het geloofwaardig genoeg. Het laatste deel verklaart ook waarom er zo weinig details in dat rechterlijke stuk staan. Grumman staat inderdaad op de linkedin page. Het zou zo maar een deal kunnen zijn van wat meer waarbij enkel dit naar buiten gaat.

Zoals je ziet kruizen berichten elkaar hier soms, het zij zo. Je stelt de zelfde juiste vragen als ik ook gedaan heb.
Het vergelijk met die koevoet verbieden slaat nergens op, omdat het om de intentie van anderen schade berokkenen gaat.

Het verschil journalling logging audit trail kun je duidelijk definieren je komt ze alle drie tegen bij een echt dbms (ACID).
Ik zou zeggen:
- journalling - doel: volledige rollback/forward functionaliteit op beschikbare commit points in de tijd voor de transacties.
Deze moet je sluitend krijgen met je backup/restore processen aansluitend op het OS.
- logging - doel: hulp voor beheerders met alle boodschappen (messages) om het stabiel / performend te houden.
- auditing - doel: doel meer specifiek wie wat veranderd en waarom.
Werk je met meerdere DBMS-sen met een echte multi-user benadering en met een front-end (presentatie) back-end (verwerking) dan zie dat de woorden vaak anders gebruikt worden. Applicaties (zelfbouw) op het DBMS lossen vragen soms zelf op waarbij ze de eisen (functiescheiding) niet goed kunnen krijgen.

Een leuke uit de oude doos, boven de 128 zitten de niet IBM tools zelf te configuren. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag200/records.htm Je zit job/step processing 34, IO/open close 14/15 RACF (het security deel) tevens DB2 (DBMS backend) CICS (DBMS frontend) MQ (soa message bus) echt alles van hardware tot en met de middleware. In de TSO/CICS kun je de invoer lijnen (keyboard input vinden). Bij de RACF record alles wat langskomt inclusief de passwords want ook je security database is een DBMS met journalling loggingg auditing.
Nee ik smijt niet alles op één hoop, ik ben me goed bewust van de verschillen en de functionaliteit.

Het is bewust dat ik een keylogger als legale optie in bijzondere gevallen. Je noemt er zelf al een, vermoeden van fraude. Denk eens aan klaslokaal met gedeelde werkstations die ook overgenomen kunnen worden. Het doel wordt dan compleet anders namelijk de invoerstroom herverdelen.

Ik weet niet of je alle ontwikkelingen gevolgd hebt. Deze oude http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf 1996 "Generally Accepted Principles and Practices for Securing Information Technology Systems" inhoud "3.13.4 Keystroke Monitoring
Keystroke monitoring is the process used to view or record both the keystrokes entered by a computer user and the computer's response during an interactive session. Keystroke monitoring is usually considered a special case of audit trails. The Department of Justice has advised that an ambiguity in U.S. law makes it unclear whether keystroke monitoring is considered equivalent to an unauthorized telephone wiretap."
Het was ver in de jaren daarvoor dat de systemen (single user single proces) onvoldoende mogelijkheden boden en men deze discussie wel eens aanging om het niet echt goed op te bouwen maar met interceptie op te lossen.
Die tijden lijken terug te keren nu omdat men niet de faciliteiten aangeboden krijgt of er vandaan gehouden wordt zodat de poging om het met zelfbouw op te lossen (DEVOPS) weer sterker wordt.