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

91–100 of 104 posts

Re: The Infosec Apocalypse

#91

Post by bawolff »

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.

Oh i agree 100% with that. Off the shelf static analysis tools have massive noise and rarely come up with useful vulns.

Most of the time they end up making a 20 page report with 500 issues that nobody reads because 499 of the issues are stupid.

(However, they can work if highly tuned to specific environment and workflow)

Re: The Infosec Apocalypse

#92

Post by Kalium »

staticassertion wrote: post #90
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'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.

I agree.

I think if there was a better standardized process for getting all the same information, I would use it preferentially in a heartbeat. From experience, trying to replicate all that info-gathering process manually is not a good answer.

Re: The Infosec Apocalypse

#93

Post by chair6 »

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…

waves, original Bandit author here. It could've done more, but pretty cool to see how useful it's been and where it's got to.. OSS is fun.

Re: The Infosec Apocalypse

#94

Post by cmiles74 »

indymike wrote: post #28

I just spent some time with someone trying to recruit me back to writing medical software. The entire interview was dominated with HIPAA related questions, which were mostly the interviewer justifying why the software sucked. And the software in question sucked in every way it could: bad UX, terrible limits on integration, data could not be exported without copy pasta magic, etc... Some of these issues really are dan…

I've worked in medical software and I want to second indymike on this, because I think it is important. The requirements for security or privacy are used as excuses to make only the smallest and most moderate of improvements to these applications. Year after year the UI stays the same and the product stays the same and the pain points for the customer's employees stays the same (remember that doctors in hospitals have some say but the business-side of the organization buy this software).

IMHO, this is one of the big excuses they use to push off interoperability. The lack of interoperability combined with the big vendors controlling the standards (i.e. HL7 or whatever) are freezing smaller vendors who might have dramatically better products out of the market.

Mark my words, the big consulting firms will use security compliance as another way to keep smaller and more agile companies (some with dramatically better products) out of the market.

Re: The Infosec Apocalypse

#95

Post by egsec »

I work in AppSec for a Very Large Company. I've worked in large companies before. These are not new trends. We have programmers who do F# and other functional programming. I would think the bigger inhibitor to functional programming is that most of the existing apps are Java or .Net so unless you are building a brand new team, you reuse the skills and technology you already have working for you.

Our devs use plenty of small open source projects. We [Security] like to recommend software that we are comfortable with, but any determination of "stacks" we leave to the actual software engineering teams. If something is pretty bad, not updated, constantly having problems, etc - we might ban it... but what's your case for using poorly engineer software given alternatives?

Not sure if mom and pop is supposed to mean commercial, but not OSS? OSS we can patch and modify if necessary. We can even PR patches back based on what our "scanners" and manual testing find.

Generally, we don't care about language, most issues are in implementation not the language, and less so in more modern languages where the creators have heard about security.

The basic type of code scanning needed for PCI and other compliance is a commodity offering and is manageable cost compared to marketing and relationship management costs needed to pursue big clients.

I am not sure the OP understands what a SOC2 report says/does. It talks about pretty high level controls and practices. You certify an app/service, not a stack. If you scan and fix your bugs and have a proactive security training, it doesn't care about how you do it. There is no golden stack that will help you pass a SOC2. You may be able to make your life easier with certain services/SaaS, but the issues come up in your practices and in the actual code implemented. If you have bugs in procedural or functional programming, its the same problem from this perspective.

Vendor due diligence? Some companies have their own questions, there are also agreed standards for these that some companies opt into. I am not sure why a big company should risk their bottom line on something unproven or that isn't ready for prime-time. It's like getting an inspection when you buy a house. In the same way, your org can improve and make improvements. This is no different then adding in features some customer wants in order to win your business.

I don't understand the ultimate point, people who build functional apps shouldn't have to care about security? It's just another non-functional requirement that helps you win a broad audience. It's the same argument that says government should regulate this or that, that financial advisers shouldn't need to act as fiduciaries. It's the cost of doing business.

Maybe the OP has some weird experiences where auditors jumped on functional programming as an issue to justify not doing more work or make their lives easier, but I don't think this is something that is a commonly held belief across audit and security (if people even know what functional programming is).

Re: The Infosec Apocalypse

#96

Post by Khaine »

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…

I don't think you understand SOC2 at all.

The business itself defines what controls they want to be tested and included in the SOC2 report. This is why SOC2 reports are simultaneously the worst and best (in most cases, only way to get assurance) assurance you can get over a third party.

The problem is, as you say people who consume SOC2 reports don't understand what they are getting.

Re: The Infosec Apocalypse

#97

Post by staticassertion »

Khaine wrote: post #96
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…

I don't think you understand SOC2 at all. The business itself defines what controls they want to be tested and included in the SOC2 report. This is why SOC2 reports are simultaneously the worst and best (in most cases, only way to get assurance) assurance you can get over a third party. The problem is, as you say people who consume SOC2 reports don't understand what they are getting.

Well I think I do understand SOC2 :)

I am well aware of how controls are defined, it was only just an hour ago that I was reviewing our controls with the feedback from our auditor.

Re: The Infosec Apocalypse

#98

Post by Khaine »

staticassertion wrote: post #97
Khaine wrote: post #96

Earlier quoted context omitted.

I don't think you understand SOC2 at all. The business itself defines what controls they want to be tested and included in the SOC2 report. This is why SOC2 reports are simultaneously the worst and best (in most cases, only way to get assurance) assurance you can get over a third party. The problem is, as you say people who consume SOC2 reports don't understand what they are getting.

Well I think I do understand SOC2 :) I am well aware of how controls are defined, it was only just an hour ago that I was reviewing our controls with the feedback from our auditor.

So how would you look to get assurance over third parties without SOC reports?

I am happy to concede that SOC reports are terrible, but at the moment they are one of the few effective ways to get assurance over third parties.

Re: The Infosec Apocalypse

#99

Post by staticassertion »

Khaine wrote: post #98
staticassertion wrote: post #97

Earlier quoted context omitted.

Well I think I do understand SOC2 :) I am well aware of how controls are defined, it was only just an hour ago that I was reviewing our controls with the feedback from our auditor.

So how would you look to get assurance over third parties without SOC reports? I am happy to concede that SOC reports are terrible, but at the moment they are one of the few effective ways to get assurance over third parties.

As I said in another post,

> This is a very hard problem. It's a regulation on a quality that is a very fast moving target with weak consensus.

Doing this in a regulatory way just isn't viable today.

> the few effective ways

I disagree that they're effective. I don't think they are. Lots of companies with a SOC2 are breached, no company that people consider 'very secure' has earned that reputation due to SOC2 (or any other compliance for that matter).

Re: The Infosec Apocalypse

#100

Post by mikorym »

goatinaboat wrote: post #46
nuker wrote: post #17

I see no links between infosec and functional programming.

The link is that FP is usually bottom up and InfoSec is top down and they fail to meet in the middle Big FP shops will have solved this of course. I doubt StanChart or Jane Street are losing any sleep over it.

I've heard a lot recently about Jane Street. Do you know a lot about them? I was curious to know their background in more detail and generally what kind of company it is, or the general attitude or atmosphere of the place. Also, why do you mention them specifically in the context of FP?
Post reply on HN