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

71–80 of 104 posts

Re: The Infosec Apocalypse

#71

Post by Mountain_Skies »

clumsysmurf wrote: post #11
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…

This. I work on an Android app written in Java. We were thinking about migrating to Kotlin years ago, but our blessed tool - Fortify - only just released a technical preview for Kotlin 1.3.50 in Fortify 20.1.0, and already Kotlin 1.4.10 is out.

My impression is that the current owners of Fortify lack the resources that HPE had and the product is suffering as a result. It's best suited for maintaining old code bases.

Re: The Infosec Apocalypse

#72

Post by Spivak »

acdha wrote: post #61
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…

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.

Re: The Infosec Apocalypse

#73

Post by Spivak »

staticassertion wrote: post #56
bob33212 wrote: post #53

Earlier quoted context omitted.

I found the SOC 2 very useful. Not because I make any Ops or Engineering changes based on the process. It made me think about risks to the business as a whole and the concept of controls to mitigate and monitor those risks. For example, what is everyone doing to minimize 3rd party risks? How do you know that the whole team understands why PII data should be avoided when possible?

SOC2 is exclusively a forcing function, you could have adopted a NIST framework for risk assessment and controls and gotten that same value, and then had an extra 6 figures of budget to implement high value security work.

Same with the CIS controls which at least come with a tool to test servers against their host benchmarks -- CIS Level 2 is a fairly practical "Server Hardening for Beginners."

Re: The Infosec Apocalypse

#74

Post by bostik »

zxcmx wrote: post #39
pc86 wrote: post #30

Earlier quoted context omitted.

What exactly is a "'first principles' scanner?"

Sorry, was perhaps poorly worded. By "first principles" I meant a static analyser working using only an understanding of the language (say, Java) and the application source code, looking over the ast/cfg etc using only built-in language rules. You get much better (read: maybe useful) results if you happen to have a "rule pack" for the specific framework you're using which provides specific hints on sources + sinks, "…

> static analyser working using only an understanding of the language [...] looking over the ast

The part I quoted is called "tainting". Or if you are more academically inclined, "data flow analysis".

When it works right, it is an incredible force multiplier in security. You get detailed, actionable and above all helpful error messages directly from CI, because as a static analysis tool it's pretty fast and can be made part of the common linting pass. As you hinted, it does require a suitable config setup and/or code annotations to mark sources and sinks. And when it does work, it can eliminate an entire class of vulnerabilities - good taint analysis will prevent you from even accidentally using user-supplied data in anything that involves relaying, storing or displaying information.

The downside is, when it doesn't work, it's a source of unhappiness. Debugging a taint failure because the AST analysis gives a false positive can be infuriating.

Re: The Infosec Apocalypse

#75

Post by tensor »

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 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.

Re: The Infosec Apocalypse

#76

Post by Kalium »

Rickasaurus wrote: post #66
Kalium wrote: post #64

Earlier quoted context omitted.

I worked in a Haskell shop, and later in a Clojure shop. In both cases, engineers were happy-go-lucky about every security or privacy concern under the sun. Often they seemed to believe that being functional saved from having to worry about validating their inputs, checking authorization, or (absurdly) having access control on their critical data stores. They told me as much on several occasions, and exhibited no int…

It's funny, I've never seen a dev team that really deeply internalized security without someone embedded who was an expert. It's just too hard, too easy to make a mistake. I don't think these tools are the answer though, they make it easy for CISOs to look good, driving down the number, but is it real security? You really need experts thinking about the security of your app. Ideally someone who thinks like a hacker.

You're right. You do need that person. IMO, it's a lot easier to accept their feedback when you understand that using a functional language offers you no significant security gains by virtue of being functional.

In my limited and less-than-universal experience as a security person thinking like a hacker, those scanners can and do enable real security enhancements. Keeping up on your patching is real security, as is having a system that can point out which inputs you didn't validate and what code paths they're on. Couple them with someone with the right experience and background, and you have the basis of a real application security program!

Which is to say that you're absolutely right. Having the right person in the right place is absolutely critical. I think it be possible that it might not always be sufficient.

Re: The Infosec Apocalypse

#77

Post by tensor »

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…

This is not my experience. I've had buyers push on specific software. E.g. I've had one push back and arbitrary state that we must use "paid" source code analysis vs an open source solution. No reason given. I've had another say that vendor supplied antivirus is not good enough (e.g. Windows Defender or Apple Xprotect). Again, no reason given.

Re: The Infosec Apocalypse

#78

Post by Kalium »

tensor wrote: post #75
Kalium wrote: post #60

Earlier quoted context omitted.

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 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 whether or not my employer should buy something, do not prioritize the health of the market or cool new technology or a good experience for the vendor over the safety of the tool and the vendor when advising on the purchasing decision. In other circumstances, I can and sometimes do make decisions different. I hope this is removes any misunderstanding that I may have engendered by failing to write clearly.

Re: The Infosec Apocalypse

#79

Post by bostik »

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…

Pray that you never have to enter domains where the security audits and assessments must be always done by an "approved supplier".

We have had to cancel engagements with suppliers who I have thoroughly enjoyed working with, and whose results were nothing short of spectacular.[ß] And all of this because certain regulators had their rules written by an established auditing firm who managed to make sure that only a select few (less than 5 globally) companies can ever perform their required assessments.

Regulatory capture through security auditing companies should deserve its own circle of Hell.

ß: Have you ever had a pentest report you could forward directly to your engineering teams and be certain that they understood the contents accurately? I have. But I can't use the supplier anymore, because they do not enjoy a royal charter.

Re: The Infosec Apocalypse

#80

Post by indymike »

maxerickson wrote: post #70
indymike wrote: post #54

Earlier quoted context omitted.

When you are making software that is used to make life and death decisions, privacy should not be the top priority.

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.
Post reply on HN