Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Infosec Apocalypse

blog.rickasaurus.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: The Infosec Apocalypse

#81

Post by tensor »

Kalium wrote: post #78
tensor wrote: post #75

Earlier quoted context omitted.

I think the fact that you don't care about challenges for small companies and new technology is a huge problem. Stopping new entrants into a space is pretty much anti-competition. Preventing new technologies is anti-innovation. Competition and innovation are the most important things to a healthy economy and market. So essentially, SOC2 both stifles innovation and ruins economies.

You're absolutely right. New entrants, new technologies, and new people in a space are critical for the health of a market. I just think it's possible that when procuring a tool for a given purpose, a company's chief concern might be about the safety of the tool and vendor rather than the health of the overall market. Your experience may well differ! Also, I feel the need to clarify my remarks. I, someone advising on…

I don't think it's on people in your position to solve this issue, but I do think it's important for people in your role to understand it and try to help by accommodating security solutions that are not "pay exorbitant fees to known security vendors."

For instance, the industry desperately needs nearly free, open security tools, that are also going to be accepted by people in your role. Too often open source solutions are immediately dismissed by compliance people simply because they are unfamiliar, or because they don't believe open source can be as good, or in the worst case because of propaganda against open source by security tool vendors.

Similarly we need free starter packages and standard templates for processes that small companies can use to get SOC2 equivalent process in practice, without paying hundreds of thousands a year to expensive auditors.

Maybe there should also be a push on vendors not to use SOC2 related security features as an enterprise tier gate. E.g. SAML or SSO is often only available on "you can't afford it" enterprise tier.

There is a lot we can do to fix these problems, but we need people to care, including people in your role.

Re: The Infosec Apocalypse

#82

Post by Kalium »

tensor wrote: post #81
Kalium wrote: post #78

Earlier quoted context omitted.

You're absolutely right. New entrants, new technologies, and new people in a space are critical for the health of a market. I just think it's possible that when procuring a tool for a given purpose, a company's chief concern might be about the safety of the tool and vendor rather than the health of the overall market. Your experience may well differ! Also, I feel the need to clarify my remarks. I, someone advising on…

I don't think it's on people in your position to solve this issue, but I do think it's important for people in your role to understand it and try to help by accommodating security solutions that are not "pay exorbitant fees to known security vendors." For instance, the industry desperately needs nearly free, open security tools, that are also going to be accepted by people in your role. Too often open source solution…

I am not someone who does not care. Please accept my deepest apologies for my repeated failures to communicate clearly. Please do not hesitate to ask for further clarification if it would be in any way helpful for you.

I fear you have mistaken me for someone who does not care about the health of the ecosystem. Merely because I am someone who advises on what's best for my employer's safety and risk management need not always mean this.

I am, for example, perfectly happy to make use of open source tooling. In many ways, I prefer it. I do not use price tag as a proxy for value. I also do not use cool new technology or vendor immaturity as a proxy for value. Your idea about making it easy for small vendors to understand what they need to do to attain compliance-equivalence is a wonderful one that should be broadly enacted immediately.

Again, please do not hesitate to ask if there is anything else I can clarify for you!

Re: The Infosec Apocalypse

#83

Post by acdha »

Spivak wrote: post #72
acdha wrote: post #61

Earlier quoted context omitted.

This is like saying Agile or DevOps is a mistake because the usual grifters sold a PowerPoint to the C-levels but didn’t change the culture. If you approach anything as a formality, you can definitely minimize the benefit you’ll get but that’s saying more about your organization.

That's the parent's point! The certification itself is completely meaningless. If a company has their SOC2 it basically tells you almost nothing about their security culture. I've never been at a company that has taken SOC audits seriously -- plenty of companies that take security seriously but SOC compliance is an exercise in paperwork not security.

If that their point, it wasn't well expressed. It doesn't seem right to call something “a grift” because you chose to treat it like a formality when you could have used it as a good faith engagement to actually try to make it better. That's why I made the Agile comparison — organizations can have positive or pointless adoption without that saying more than “you get out of it what you put into it”.

Re: The Infosec Apocalypse

#84

Post by Rickasaurus »

zxcmx wrote: post #10
Mountain_Skies wrote: post #7

I recently did an extensive competitive analysis of SAST tools for a client. Anyone who is thinking about buying one of these tools should pay attention to what versions of each language they support. Also try to get old release notes in order to determine when they first supported a particular language version. Many vendors take a good long time to support new versions of languages, even mainstream ones like Java an…

Not just languages - Generally if the scanner isn't aware of the specific framework you're using it's unable to find entrypoints or reliably figure out sources / sinks and filters. Many modern frameworks have one or more of: dynamic configuration, compile time annotations, reflection, IoC etc which make it very hard for a "first principles" scanner to make sense of what can actually happen at runtime.

I didn't write about this because it wasn't toward my exact point about FP, but you're totally right. This will be equally as chilling for new web frameworks.

Re: The Infosec Apocalypse

#85

Post by finnthehuman »

>There are new forces at play which will calcify current software stacks and make it extremely hard for existing or new entrants to see similar success without a massive coordinated push backed by big enterprise companies [...] enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down.

The security community got exactly what they asked for.

Security people were selling fear of insecurity with limited actionable advice for security to come into products/systems bottom-up, so the business has to solve it with process. Breaking into computers is fun and all, but throw around words like "risk analysis" to sound like hot shit for too long and you end up with comprehensive risk analysis process that spans beyond the bits of tech you want to play with.

I work in a highly-regulated domain so software security is just another type of risk analysis we do. So shrug whatevs this doesn't calcify us more than we are already calcified. I just think it's cute that infosec people thought they were hackers, but didn't realize they're another flavor of boring business analyst telling the kids to turn down their music and develop software to their requirements.

Re: The Infosec Apocalypse

#86

Post by marcosdumay »

nautilus12 wrote: post #36

Yeah im confused by this article. Why would this push functional programming into a small niche? Is it just because the scanners are only written small range of languages like C# or javascript? Seems like functional programming makes for BETTER security scanning all around. If anything I actually see this potentially giving FP a boost, unless the scanners are just surface level and are adopted as a matter of faith, a…

> Is it just because the scanners are only written small range of languages like C# or javascript?

Yes.

> Seems like functional programming makes for BETTER security scanning all around.

Yes.

> unless the scanners are just surface level and are adopted as a matter of faith

Kinda. They are very useful, as they catch all those stuff that should have been designed out of the language/framework to start with. They are not something to get cracked, but they also won't discover any deep issue.

Re: The Infosec Apocalypse

#87

Post by staticassertion »

acdha wrote: post #83
Spivak wrote: post #72

Earlier quoted context omitted.

That's the parent's point! The certification itself is completely meaningless. If a company has their SOC2 it basically tells you almost nothing about their security culture. I've never been at a company that has taken SOC audits seriously -- plenty of companies that take security seriously but SOC compliance is an exercise in paperwork not security.

If that their point, it wasn't well expressed. It doesn't seem right to call something “a grift” because you chose to treat it like a formality when you could have used it as a good faith engagement to actually try to make it better. That's why I made the Agile comparison — organizations can have positive or pointless adoption without that saying more than “you get out of it what you put into it”.

I call it a grift because it really feels like it. It's this weird "you have to do this or else" thing that provides 0 additional value (SOC2 is not prescriptive, it is just a forcing function, you could have... just done it).

A bunch of unqualified people coming in to rank the unrankable in a vague, gameable, expensive way is my definition of a grift. Then, on top of that, you have a sort of ring of high status organizations that will audit you and charge a fortune, but they've convinced all of these other orgs that their audits are Definitely Better (companies audited by them get breached all the time too), and now you've got this whole racket on top of the grift.

Agile isn't forced on anyone. People won't skip over your product because you're "not really doing agile" or whatever. You don't get forced into yearly audits where you pay some outsider with an "agile certification" and 0 technical knowledge to take up multiple engineers for months to write reports.

This post explains more: https://news.ycombinator.com/item?id=24505894

Re: The Infosec Apocalypse

#88

Post by masonhensley »

pc86 wrote: post #32
smu wrote: post #14

I've done more than my fair share of vendor due diligences (and audits, action plans and contract reviews,..) To me this is a non-issue, because customers almost always ask for types of security checks, not for specific tooling (ie: asking for source code analysis vs asking for veracode). As a rule, compliance/government folks will be concerned about the types of security measures you have in place and not about the…

Just as a counterpoint, about 2/3 of the enterprise contracts I've either helped fulfill or reviewed has specified the tool (and sometimes a minimum version but that was only twice out of ~25-30 contracts I've seen). That being said, for the mast majority of those (90%+) the client was very reasonable, and if we had a good reason to remove a specific reference to Veracode, for example, they would probably be fine wit…

My experience - primarily in healthcare data as a vendor... Employers & Insurance.

Client security teams have been very reasonable on deviations to their massive spreadsheet checklists.

On one hand, I think that if you, as a vendor, reply back with a few "well, we do X instead of Y in the same spirit" they will probably believe & trust your answers more than a spreadsheet returned in 2 hours with "yes/in compliance" for each question.

Re: The Infosec Apocalypse

#89

Post by maxerickson »

indymike wrote: post #80
maxerickson wrote: post #70

Earlier quoted context omitted.

The idea that there is a single "top priority" is the problem. There's inevitably going to be a list of primary criteria, with the specific situation driving how they are balanced.

Man who hunts two rabbits starves.

Chases maybe.

Putting a snare where two rabbits are active is just as good or better than putting it where one rabbit is active.

Re: The Infosec Apocalypse

#90

Post by staticassertion »

Kalium wrote: post #60
staticassertion wrote: post #40

I wish we could just all reject SOC2, it's such a grift. Bankers come in to read some docs (that they don't understand), look at screenshots (that they don't understand), take up 100s of thousands in cash and time, and then write a document (that they don't understand) that no one will read or care about (except to fuel their own SOC2). The harm is so significant. Tons of these due diligence terms are driven not by a…

Being a security person myself, I've found plenty of value in reading SOC2 reports. They're one of the few relatively standardized ways to address the laundry list of vendor due diligence questions. Is it a good experience for small companies? No. Does it make it easy for your vendors to use cool new technologies? No. Do I, someone advising on whether or not we should buy something, care about either of those in the…

I'm not saying that no human being has ever derived value from a SOC2. I'm saying that the process around SOC2 is a grift.

The fact that it also causes harm to small companies, and detracts from resources for companies that actually care about security, just makes it a particularly harmful grift.

Post reply on HN