i dont know about hippa/sox but i did recently have the "pleasure" of creating a pci-dss v1.1 compliant system from pretty much the ground up on the freebsd platform and have read all 16 (wow!) pages of the pci-dss 1.1 "spec" (if you can call it that, i put that in quotes because it it doesnt "spec"ify anything. at least it is short read albeit a vague one) the following is a rant. however if you read to the bottom (or skip there) there is a reward of a paragraph actually more directly pertinent to the original ask /. question :)

it (pci-dss) eerily reminded me of iso 9001. (i have a little experience in qual. assurance of manufacturing.) basically [pci-dss|iso9001], while its advocates will try and trumpet [security|quality], has nothing to do with either, and more to do with documentation and accountability. (ie whos responsible ie who gets fired/resign (after they've already pocketed enough money so that its actually basically a retirement) so that another scapegoat can be brought in to take his place) sure, documenting your process has always been a cornerstone of [security|quality] but anyone worth their weight in horse-sh^H^Hmanure already knew that and already did that.

[pci-dss|iso9001] seems to me (a small business operator) to mean more about burying the little guy in a mess of paperwork and red tape while letting the big guys pat themselves on the back with another acronym or seal-of-approval that in the end gets so watered down and turns into just another way for fool-hearty consumers/customers to increase their complacency (complacent-fool consumers both a. deserve to be separated from their money quickly and b. are in my opinion one of the major problems w/ american society) rather than study beyond the flashy outter packaging (in a manner of speaking) what they are buying.

and i dont have much experience with SOX but from the whiff of it based on what some colleagues have told me, is roughly the same thing (swap consumers w/ investors in the above text), despite glowing reviews in a recent usa today article on its 5th birthday. (usa today basically credits SOX for all of the US's economic growth since its inception after the post-enron market bomb, not the fact that the fear of being caught still looms in the air like a stench and so would-be corruptees might just be chilling out for the time being, seeing that 5 years is nothing the grand scheme. however my hypothesis is that they in fact aren't chilling out at all, and are going at it just as strong or stronger, because from what i have seen in business, i would tend to think that: just like there is nothing really stopping a iso9001 certified company from producing sh^H^Hpoor quality products, SOX smells like just a better way to bury the real story in cooked-books that are now just that much deeper. i know, i know, now the board is responsible and not just the CEO, and its a legal crime and they can't claim plausible deniability anymore, all good steps in the right direction, but that only matters if you get caught and my point is that SOX is just more paper to hide under so they dont get caught) (ok please label all flame replies telling me i dont know squat about SOX by keeping SOX in your subject while taking PCI-DSS out of your subject line if it no longer has anything to do with pci-dss, and do please enlighten us)

back to pci-dss: as consultants first and developers second, we reviewed handfulls of pci-dss compliant "solutions" before resorting to a custom built system. despite trying to scare those like us out of it, with a little patience and attention to detail we little guys could still implement a pci-dss compliant system that was WAY better than many systems i wont go into bashing here, and all for the cost of some lower priced of the pre-cooked "solutions".

to an experienced developer, the pci-dss "spec" reads like: 1. dont be so stupid, 2. pull yer head out of yer as^H^Hrear-end, 3. dont give credit card numbers to bums, 4. see 3, 5. pay one of our friends (big companies) money, 6. do 5 some more, 7-9. see 3, 10. logging, (i told you i'd eventually address the original ask /.) 11. check it every once and a while dont just let it rot oh yeah and do 5 some more, 12. see 1... oh yeah, and somewhere in there theres something about this stuff called "incripshun" i think.

ok, so on to pci-dss section 10! your question, logging! specifically 10.5: "Secure audit trails so they cannot be altered." and more specifically 10.5.2: "Protect audit trail files from unauthorized modifications" plus 10.5.3: "Promptly back-up audit trail files to a centralized log server or media that is difficult to alter" plus 10.5.5: "Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts."

i wont go into details of how we implemented each, just tell you how lax some of the big expensive packages got away with them while still complying with 11.2 (which is getting PCI-DSS certified by one of the big friends of the big 4 credit transaction processing companies... which based on the quality, i cant even fathom what being certified to be a certifier entails, other than being someones nephew or kickbacks by the bushel-full)

10.5.2? usually plain files in a plain file system or a pretty standard db, simply (like a few users pointed out) written thru an append-only api that uses udp to another machine (not much unlike the syslog setup mentioned by many /.ers) 10.5.3? if "promptly" is more than weekly, basically nothing more than a glorified obfuscated redundant duplication of what i described in 10.5.2, with no added security beyond the added obscurity or the addition of 10.5.5 with 10.5.3 if it wasnt already coupled with 10.5.2 like it should have, or the line-printer paper-trail recommended by /.ers earlier, or optionally a combination of both. if "promptly" is weekly/monthly then burn cd's. whichever you choose, databases, cd's and/or paper, had the added benefit of 10.5.5 which in most was a md5 or sha1 based (one even used md4!, but a minority did use sha256 or sha512) part of some (usually) weak PKI implementation.

notice i say usually and credit the minority for standing slightly above the abysmal. so for the most part, while when you "colored inside the lines" things operate within the loose vague pci-dss definition of security, 80% of these solutions ran on windows where their solution to sections 1. and 5. was along the lines of "we recommend one of our partners on this short list of the most popular crappy windows based security packages that are so easy to target by even the most rudimentary malware or unintelligent of unscrupulous individuals"

while there were a few decent implementations, most would quickly fall prey to any number of security breaches rendering it trivial to rewrite the logs, access the private keys, resign changed logs and database records, etc, but they had passed the certified testers of 11.2.

not to mention none of these do anything to protect against the knowing individual burning/shredding the old paper log, rerecording new modified cds and labeling them as old, etc. (some /.ers seem to be futilely searching for the solution to that, while others are pointing out that its impossible. but /. is definitely the place to brainstorm this!) if that is what the OP is searching for then they don't understand that the purpose of things like pci-dss (and SOX for that matter) is about following a process and having accountability. ie each of these packages is as much about its process manual as it is about the software.

the process manual is like, "ok, since the certifier has certified your installation recently enough (they certify the installed implementation regularly not just that the software package creates a certifiable implementation, more periodic cost) you, the ceo/owner/manager/etc (two or more for pci-dss) sign on the dotted line (physical paper trail) here that this log, dates foo thru bar, hash blahblah, is legit" and then you have those individuals are responsible. trouble is that they usually have no idea what is really going on behind the scenes and they just have the solution provider's word that everything is working just great and that since they checked them out 2 months ago then the hash ffd93f16876049265fbaef4da268dd0e probably is right. but just like earlier articles on /. have talked about the unwitting users of broken slot machines and atms being subject to prosecution instead of the writers/producers of the shoddy low-security software, who do you think is going to take the fall if one of these poor quality pci-dss systems is breached? john q. storeowner is ultimately the one responsible and the solutions provider will deny responsibility because it was good when they checked it 2 months ago and you didnt keep your virus defs up to date or you didnt scan hard enough or long enough or every five seconds or you didnt follow section 18 paragraph 87 a, b, c, and d of their terms of service.

see the way i see it these things like pci-dss and sox dont get rid of the problem of plausible deniability they just spread it around more while hiding the fact that the responsibility ultimately lies with the consumer/investor and allowing the big guys to sweep their issues/responsibilities under the rug after selling the consumer/investor on the illusion that they take responsibility by way of some seal of approval. i think within the next decade we will find a whole new wave of post-sox big-business scandals with a new flavor the SEC hasnt caught wind of yet, (or worse is in on or happy to ignore as long as they catch a few non-sox-compliance-technicalities so that the govt can pat itself on the back and convince the people of what a good job they're doing of stamping out corruption) these real scandals probably wont be uncovered by the SEC but rather by the last few vestiges of quality media and investigative reporting. maybe im being hard on the SEC, someone clue me in here, like i said i have a lot more experience with iso9001 and pci-dss than sox or sec, i just think ive been noticing a certain trend in my country ever since i was 12.

and as a side note i have no knowledge or experience with hippa but i probably dont even want to know.