this post was submitted on 16 May 2024
41 points (93.6% liked)

Programming

17424 readers
25 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

I need to help auditing a project from another team.
I got the pointers on what's expected to be checked, but I don't have like templates for documents for what's expected from an audit report which also means I'm not sure what's the usual process to conduct an internal audit.
I mean I might as well read the whole repo, but maybe that's too much?

Any help or pointers on what I need to investigate to get started would be great!

you are viewing a single comment's thread
view the rest of the comments
[–] xmunk@sh.itjust.works 16 points 6 months ago (1 children)

For what purposes are you auditing this software. Auditing is always done to prove something is appropriate for some usage and what that audit should involve depends on that usage and, additionally, factors of trust between you and the author.

Would you be comfortable supplying some additional information about what you (or whoever asked you to run the audit) expects out of the audit.

[–] pe1uca@lemmy.pe1uca.dev 3 points 6 months ago (2 children)

It's regarding appropriate handling of user information.
I'm not sure it includes PII. Basically it's a ticketing system.
The pointers I got are: the software is secure and reliable to store the data and be able to be queried to understand the updates the data had.

[–] xmunk@sh.itjust.works 7 points 6 months ago

Is this related to highly sensitive PII (like hippa or whatever covers local health-care record treatment)? If so, I'd strongly suggest not doing anything and seeking a remedy from contractual obligations by the vendor (i.e. seek HIPPA Ready software or a vendor willing to make that promise).

If not, you'll definitely want to focus on data persistence and transmission.

Make sure there aren't outgoing network calls to fixed locations (if they're for error reporting to the vendor you can either ask if they can disable the reporting, black hole the reporting with network configuration or carefully inspect the way data gets to that reporting and ensure user data can't be captured - a common oversight being logging function parameters).

Make sure the persistence is secure by looking at the main persistence module (i.e. a database or flat file) to make sure unnecessary information isn't being stored, verification only information is being written to persistence through one way hashes, and data that should be two-way encrypted is. Then double check the same stuff with regards to secondary persistence methods - again a huge issue here is logging.

Those two points are where I'd suggest focusing the majority of your effort but, back to the hippa part, make sure you're comfortable doing this. It's pretty easy for auditors to be the fall guys if something goes wrong so if you want to be careful one approach is to carefully document what you've checked for and how you checked for them then get someone above you to sign off that your level of auditing was sufficient - if shit ever does hit the fan you'll be less exposed.

[–] Windex007@lemmy.world 6 points 6 months ago

Ah, an auditability audit.