The Infosec Apocalypse • Hacker News Board

Re: The Infosec Apocalypse

#61

Post by acdha » Thu, Sep 17, 2020, 3:59 PM UTC

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.

Re: The Infosec Apocalypse

#62

Post by Kalium » Thu, Sep 17, 2020, 4:00 PM UTC

jcims wrote: post #45

ithkuil wrote: post #27

Earlier quoted context omitted.

I agree; my response was to the wording present in TFA, which seemed to imply that enterprises expected engineers to handle security and were surprised they didn't and hence now are attempting to force a top-down approach the whole thing will be secure _despite_ engineers doing the same things as before. Tooling helps; no question about that. But you can't assume you're engineering team can be oblivious to security c…

Totally agree. One option is to make static scans a tollgate only at higher application risk levels and/or exposure. For example, low/medium risk internal automation and telemetry tooling? Go nuts. Internet facing, regulated, high/critical risk? Need code scans.

That sort of division assumes you can be completely sure about how a system will be used in the future. I've definitely seen internal systems deployed in a public-facing capacity because someone found a useful reason to do it.

How are you going to do that, if the internal tool is written in something that is not supported by SAST tooling?

Re: The Infosec Apocalypse

#63

Post by etherwaste » Thu, Sep 17, 2020, 4:01 PM UTC

skee0083 wrote: post #58

Best way to stop hackers is to just start handing out life sentences. that will put a stop to it. or even better. death penalties. like seriously just get a life. society doesn't tolerate thieves IRL so why would we tolerate them in the internet? Backdoors and exploits exist everywhere. no computer or building is 100% secure. we know this. so stop acting like you are doing everyone a favor by exposing them.

Not only is this psychopathic, to prioritize property above human life, to have such draconian sentences handed out so carelessly, not only is it so inhumane, to value human life so little, but it's also just factually and objectively bad policy.

We learned from history and the Bloody Code, that when you have draconian sentences it means people will "upgrade" their crime since there is no difference between say "minor theft" and "major theft," but it also encourages horrible acts to avoid draconian punishments (murder is often involved in high risk crimes that have draconian sentences). But we also have most criminology and justice theory based on this modern principle that the punishment must fit the crime for law to be effective under the punitive system.

On a technical note, it is doing a favor to expose the exploits, as long as it's handled in an appropriate way, I mean that's literally why companies pay a ton of money to white hat hackers, and why there are bug bounties, etc. But even more that's why someone like Edward Snowden is a hero.

Re: The Infosec Apocalypse

#64

Post by Kalium » Thu, Sep 17, 2020, 4:02 PM UTC

Rickasaurus wrote: post #57

bawolff wrote: post #5

Earlier quoted context omitted.

"Apocolypse" is still a pretty strong word for failing to break into a market because your product doesn't meet the user's requirements.

Hi Author here, I'm just as worried about "established FP but globally niche" tech like Haskell or F# as I am about new tech. I've surveyed options and there's nothing available.

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 interest in altering these beliefs.

As you might guess, this drove me nuts. In both cases it eventually blew up in their faces and the events proved to be free of side effects. Their imperative colleagues did not have the same mindsets.

If those two shops are in any way representative, then it may perhaps be worth considering very carefully if keeping cool new technologies away from serious usage could in some scenarios be a win.

Re: The Infosec Apocalypse

#65

Post by acdha » Thu, Sep 17, 2020, 4:04 PM UTC

beh9540 wrote: post #42

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 cannot be stated enough. The company I worked for purchased "the leading gartner SAST testing solution" before they even started a project and had a framework chosen. It turned out the SAST solution didn't support the latest major version of the framework we were using at the time, and didn't support the latest version of the language we were using. Even worse, it never seemed to ever report an issue, and took h…

Fortify took almost a decade to support Python 3 and there were some hefty lags on Java updates, where multiple times it was like “do you want to use the supported Java or the one which Fortify can scan?”

Re: The Infosec Apocalypse

#66

Post by Rickasaurus » Thu, Sep 17, 2020, 4:13 PM UTC

Kalium wrote: post #64

Rickasaurus wrote: post #57

Earlier quoted context omitted.

Hi Author here, I'm just as worried about "established FP but globally niche" tech like Haskell or F# as I am about new tech. I've surveyed options and there's nothing available.

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.

Re: The Infosec Apocalypse

#67

Post by Mountain_Skies » Thu, Sep 17, 2020, 4:18 PM UTC

newera2016 wrote: post #47

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…

Wow. Great. Would you be able to publish your analysis?

Unfortunately I cannot as it is not my property. Plus one vendor made my client and myself sign an NDA even for the most basic information. What I can say is to not put too much faith in the Gartner Magic Quadrant for this space. The best thing to do is select a couple of representative projects for your company and get each vendor to let you do a POC and then compare the scan results from each. The process of making this happen will be long and painful as it is managed mostly by sales teams rather than the tech folks. In the end though, it's the best way to know what will work for your particular set of development technologies. The good news is pretty much every vendor was receptive to the idea of doing a POC even if it took a while to get each one set up.

Re: The Infosec Apocalypse

#68

Post by tru3_power » Thu, Sep 17, 2020, 4:30 PM UTC

airza wrote: post #48

zxcmx wrote: post #10

Earlier quoted context omitted.

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.

Even Fortify and other tools which have to compile beforehand don't do so well IMO. Someone is going to come up with an actually good SAST and print money...

I’ve had really good experiences with Fortify so far. It took me a lot of hours to figure out how to write custom rules but once I was able to do so it became super valuable.

Re: The Infosec Apocalypse

#69

Post by tylerrobinson » Thu, Sep 17, 2020, 4:30 PM UTC

indymike wrote: post #54

maxerickson wrote: post #35

Earlier quoted context omitted.

What's wrong with and? Obviously you can't literally have 4 top priorities, but patient privacy isn't some dumb irrelevancy.

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

I also work on software in the medical industry. Maybe you were talking about the specific firm you were interviewing with, but patient safety (accuracy) is absolutely the highest concern in my team. That doesn’t mean we cut corners on security and privacy, it means that all must be done correctly to be successful.

Re: The Infosec Apocalypse

#70

Post by maxerickson » Thu, Sep 17, 2020, 4:30 PM UTC

indymike wrote: post #54

maxerickson wrote: post #35

Earlier quoted context omitted.

What's wrong with and? Obviously you can't literally have 4 top priorities, but patient privacy isn't some dumb irrelevancy.

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.