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

21–30 of 104 posts

Re: The Infosec Apocalypse

#21

Post by thinkharderdev »

ithkuil wrote: post #18

> In the wake of so many data leaks and hacking events enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. As if enterprises were not responsible for not properly budgeting security concerns in their engineering teams. I guess it's easier to just buy a tool that will force a process overhaul, rather than doing a much more thorough process ov…

Those things are not mutually exclusive. And the original framing that enterprises "no longer trust their developers and SREs to take care of security" is a bit leading as well. Real, practical security is a mixture of dedicated security teams doing in depth analysis and pen testing, developers and SREs building secure solutions and automated tooling that does basic sanity checks.

Re: The Infosec Apocalypse

#22

Post by thinkharderdev »

bawolff wrote: post #4

Meh, if you want your niche tool to break into big enterprise, you have to deal with compliance hoops. That's just the cost of doing business with big enterprise, certainly not a new thing. If anything, in the long term that's probably a benefit to fancy functional programming languages with complex type systems - they provide much more info for static analysis tools to work with (static analysis is pretty highly rel…

And this is probably a really good thing. We should want bleeding edge tech and languages to get battle hardened in smaller stakes products and open source projects before we try and use them at scale.

Re: The Infosec Apocalypse

#23

Post by thinkharderdev »

raesene9 wrote: post #15

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption of new technologies if their tooling doesn't support them. I don't think I've ever seen a company where the security tooling team had that kind of authority or pull. I've seen plenty where the first time the security team hears about a new technology is after…

I think they are arguing that this is changing now. When I first started software engineering ~15 years ago, it was pretty common for enterprises to exert quite a lot of control over what tech could be used. You had to use some solution from the "approved" list of languages/frameworks/versions (that was always hilariously out of date). Then that swung in the opposite direction (mostly concurrently with cloud adoption where dev teams were in charge of their own infrastructure) where individual teams had complete free reign to choose their own tech. The author is arguing that things are now swinging back in the other direction and it's largely driven by security considerations. So its not "you have to use something on the approved list of tech maintained by the Enterprise Architecture gods" but rather "you have to use something that is supported by our enterprise SAST solution." It will still likely be more lax than it was back in the old days because it is harder to enforce those restrictions in a world where the dev team manages their own cloud infrastructure, but still.

Re: The Infosec Apocalypse

#24

Post by user5994461 »

raesene9 wrote: post #15

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption of new technologies if their tooling doesn't support them. I don't think I've ever seen a company where the security tooling team had that kind of authority or pull. I've seen plenty where the first time the security team hears about a new technology is after…

Had that in JP Morgan. New fancy things better work with all the tooling in place otherwise you can forget about using it (code review, unit tests, linter, deployment, packaging, vulnerability scanning, etc...).

Honestly, this was great, this prevented developers and new graduates from rewriting every goddamn thing in the language du jour.

I hope I never have to work in an organization with 100+ developers that doesn't enforce some standards. It's impossible to join a project and collaborate with other teams when every single developer/project decided to use its own language and make its own deployment system.

Re: The Infosec Apocalypse

#25

Post by k4ch0w »

I'm on the side of sending the big list of vendor due diligence to a potential product. I know it's a pain to ask about GDPR, how you store/delete data, off board employees, is SSO everywhere, do you have 2FA and how you access your servers.

We try to keep a high standard of tooling to protect our customers and company data. It's really not about bogging you down, I know it sucks. It sucks hard. It's about ensuring when we upload data to your SaaS, we know it's in good hands that have been vetted.

The good news is, if you make it through it once other big companies start flooding to you as well and it becomes much easier to deal with them as you've been through the intensive process before.

I deal with a lot of deals and if you're building a startup up it's a lot easier to think about security at the start then retrofit and fix it all at the end.

Re: The Infosec Apocalypse

#26

Post by raesene9 »

thinkharderdev wrote: post #23
raesene9 wrote: post #15

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption of new technologies if their tooling doesn't support them. I don't think I've ever seen a company where the security tooling team had that kind of authority or pull. I've seen plenty where the first time the security team hears about a new technology is after…

I think they are arguing that this is changing now. When I first started software engineering ~15 years ago, it was pretty common for enterprises to exert quite a lot of control over what tech could be used. You had to use some solution from the "approved" list of languages/frameworks/versions (that was always hilariously out of date). Then that swung in the opposite direction (mostly concurrently with cloud adoption…

sure, and it's the argument that it's swinging back in the favour of centralised control that I don't buy.

I look at major enterprises quickly adopting what are still quite new technologies, a good example being the uptake of things that come under the cloud native banner and that doesn't tell me that things are becoming more centralised/controlled.

I've spoken to multiple security teams looking at container security who've said things along the lines of "this is getting deployed whether we want it or not, so we're doing our best to keep up"

Ofc my examples will just be anecdotal, but that's what I'm seeing.

Re: The Infosec Apocalypse

#27

Post by ithkuil »

jcims wrote: post #20
ithkuil wrote: post #18

> In the wake of so many data leaks and hacking events enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. As if enterprises were not responsible for not properly budgeting security concerns in their engineering teams. I guess it's easier to just buy a tool that will force a process overhaul, rather than doing a much more thorough process ov…

This isn’t worded correctly based on my experience. It should say ‘enterprises no longer trust their developers and SREs alone to take care of security,’. Devs and SRE still have a very important role as SAST and DAST tools only catch a portion of security issues in code and are generally useless for gauging architectural/deployment/runtime issues.

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 concerns. You need to train, hire and equip your teams appropriately. You need to set the right incentives. Just limiting the kinds of software stacks you're allowed to use seems shortsighted.

Re: The Infosec Apocalypse

#28

Post by indymike »

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 dangerous because clinicians have to spend so much time fighting to make things work or doing immense amounts of double and triple data entry. Oh, and every time the justification was because of HIPAA requirements or infosec.

It made me realize that we do not know how to make software well enough to regulate it safely, and no, I do not want to go work in a sector where prioirity one is complying with some privacy regulation when the top priority should be accuracy of diagnostic, reliability of a system or eliminating operator error.

Re: The Infosec Apocalypse

#29

Post by sheeshkebab »

user5994461 wrote: post #24
raesene9 wrote: post #15

I've got to say, I don't agree with this. The predicate of the argument appears to be that the team managing the VA/SAST platform will be able to block adoption of new technologies if their tooling doesn't support them. I don't think I've ever seen a company where the security tooling team had that kind of authority or pull. I've seen plenty where the first time the security team hears about a new technology is after…

Had that in JP Morgan. New fancy things better work with all the tooling in place otherwise you can forget about using it (code review, unit tests, linter, deployment, packaging, vulnerability scanning, etc...). Honestly, this was great, this prevented developers and new graduates from rewriting every goddamn thing in the language du jour. I hope I never have to work in an organization with 100+ developers that doesn…

The quality of consumer facing major banking websites shows how well this calcified development “culture” works in practice and long term.

Re: The Infosec Apocalypse

#30

Post by pc86 »

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.

What exactly is a "'first principles' scanner?"
Post reply on HN