[cj]

> it’s why frequent pentests are important.

Unfortunately a lot of pen testing services have devolved into "We know you need a report for SOC 2, but don't worry, we can do some light security testing and generate a report for you in a few days and you'll be able to check the box for compliance"

Which is guess is better than nothing.

If anyone works at a company that does pen tests for compliance purposes, I'd recommend advocating internally for doing a "quick, easy, and cheap" pen test to "check the box" for compliance, _alongside_ a more comprehensive pen test (maybe call it something other than a "pen test" to convince internal stakeholders who might be afraid that a 2nd in depth pen test might weaken their compliance posture since the report is typically shared with sales prospects)

Ideally grey box or white box testing (provide access to codebase / infrastructure to make finding bugs easier). Most pen tests done for compliance purposes are black-box and limit their findings as a result.

[dylan604]

I recently ran into something along the lines of your devolved pentest concept. I have a public facing webapp, and the report came back with a list of "critical" issues that are solved by yum update. Nothing about vulnerability to session jacking or anything along the lines of requiring actual work. I was a few steps removed from the actual testing, so who knows what was lost in translation and it being the first time I've ever had something I worked on pen tested. However, I feel this was more of a script kiddie port scan level of effort vs actually trying to provide useful security advice. The whole process was very disappointing.

[alaxapta7]

I've seen worse. Couple years back, there was an audit that included an internal system I've been working on. It was running on Debian oldstable because of a vital proprietary library I wasn't able to get working on stable at the time, but it had unattended upgrades set up and all that.

The company made some basic port scan and established that we're running outdated and vulnerable version of Apache. I found the act of explaining the concept of backports to a "pentester" to be physically painful.

They didn't get paid and another company was entrusted with the audit.

[pixl97]

This is why I always attempt to turn off as much version information output as possible from any service. Make the pentester do their homework and not just look at "Apache 2.XX"

Hopefully you also have an internal control that looks at actual package versions installed on the server.

[alaxapta7]

Normally I do that too, but this was fairly new and internal application that was still in development, so that's why it was there. And if it wasn't for this incident, they might actually trick our management into thinking they're somehow qualified to carry out such an audit.

[dylan604]

This is actually a take away that I did implement. it's one of those that's not actively a vuln, but might provide info on what other attacks to try.

[im3w1l]

How behind on yum updates were you anyway?

[dylan604]

not very. i guess i was too cavalier in hand waving it as a yum update. some of it was switching to a new repo with the most recent version available. but that was still just using yum. not like it required changes to the code base and workflow. maybe it was an amazon-linux-extras command for the actual package change, but still.

[oooyay]

Narrowly scoped tests designed for specific compliance requirements are fine. They lower the barrier to entry to some degree for even getting testing and still, or often enough, return viable results. There's also SAAS companies that have emerged that effectively run a scripted analysis of cloud resources. The two together are more economical and still accomplish the goals that having compliance in the first place sets out.

When I was consulting architecture and code review were separate services with a very different rate from pentesting. Similar goals but far more expensive.