[deleted]
The Infosec Apocalypse
31–40 of 104 posts
Re: The Infosec Apocalypse
#32I'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 with it. But I could definitely see it becoming an issue if you just sign the contract to close the deal and try to get out of using Veracode later, especially with whatever the client's internal approvals/review process is.
Re: The Infosec Apocalypse
#33Earlier quoted context omitted.
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.
I'd rather my bank not loose my money than have a cool website though.
Re: The Infosec Apocalypse
#34Earlier quoted context omitted.
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.
If you're implying Chase the consumer bank, it's separate from JP Morgan.
Re: The Infosec Apocalypse
#35I 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…
What's wrong with and?
Obviously you can't literally have 4 top priorities, but patient privacy isn't some dumb irrelevancy.
Re: The Infosec Apocalypse
#36Yeah 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, all good and well until one of them gets cracked, dynamic languages compared to compiled are like swiss cheese
Re: The Infosec Apocalypse
#37Earlier quoted context omitted.
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…
Yeah, I would mostly agree. I have noticed personally at my (largish) company a bit of a shift back towards centralized control, but only slightly. One thing that does seem very different now is that there is a lot more pressure on the vendors of SAST and other security products to support newer tech stacks. And if the big boys won't then there are always a huge number of smaller players ready to jump in to take advantage of that opening. The number of products just in the Serverless space offering "next-gen" WAF solutions is pretty amazing given how recent large scale adoption of Serverless stacks has been.
Re: The Infosec Apocalypse
#38[deleted]
Re: The Infosec Apocalypse
#39Earlier 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.
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, "gotchas" and how things are wired together. As a somewhat obsolete example, I would not expect a sast working only from "first principles" to be able to do anything useful with a Spring XML configuration file.
On the whole my experience is that these things work very well on certain types of codebases - e.g. naive PHP they can "go to town" because of the huge footgun surface and fairly direct control and data transfer.
Stuff with lots of "magical" framework features and indirection (where even a human reviewer can often have trouble finding the implementation from the interface being invoked) they often silently fail to do anything useful.
Re: The Infosec Apocalypse
#40I 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 any security engineer, but by a legal or compliance team - I've even had members of the security team outright apologize for having to send it over.