11 ms·

The Infosec Apocalypse

159 points by chillax 6y ago

RajSinghLA 6y ago
Apocalypse is a strong word for a post that ends with no real prediction.
- saagarjha 6y ago
  It seems to me that the author is concerned that a desire for vulnerability scanning will prevent new languages from entering use because these tools won’t support them.
  - bawolff 6y ago
    "Apocolypse" is still a pretty strong word for failing to break into a market because your product doesn't meet the user's requirements.
    - Rickasaurus 6y ago
      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.
      - Kalium 6y ago
        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.
        Rickasaurus 6y ago
        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.
        Kalium 6y ago
        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.
        bawolff 6y ago
        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)
bawolff 6y ago
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 related to type theory)
- iso1631 6y ago
  > That's just the cost of doing business with big enterprise, certainly not a new thing. This feature is why small companies can compete with big enterprises. The big ones get the economies of scale, but they also get bogged down by being inagile.
- thinkharderdev 6y ago
  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.
novok 6y ago
Whee more compliance calcification that misses the point to slow down your large competitors with.
Mountain_Skies 6y ago
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 and the .net family. None of them are particularly helpful in getting this information to you. They have their marketing checklists and information deeper than this can be hard to come by from the salespeople. A few were scared of letting us have this information at all once they knew it was for a competitive analysis. That's a sign that they take a long time to support new language versions. In many companies adoption of new language versions happen organically at the developer level, often within days of the new version being released. Even if the system admins try to press the brakes a bit on deploying the new version on production servers, the pressure is there for it to happen. SAST vendors typically are not going to be able to keep pace, which will make your developers unhappy or even give them an excuse for not using the expensive tool you purchased.
- zxcmx 6y ago
  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.
  - pc86 6y ago
    What exactly is a "'first principles' scanner?"
    - zxcmx 6y ago
      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.
jerome-jh 6y ago
Static analysis is coming to FOSS as well. There is no mystery tech behind that. Compilers actually do quite a bit of analysis: see Rust. Of course FOSS tools will probably have rougher edges, but the entire field will commoditize in the coming years. There are already a number of competing tools as mentioned by the article. The usual FP vs IP argument is not relevant: the LLVM intermediate representation is FP.
pubkraal 6y ago
The static analysis, but also software component analysis tooling are really incredibly helpful though and should really contribute to releasing stable products as well -- it's not just here to satisfy your customers management types, it's there to actually make sure your tool doesn't have 5 RCEs active at any point in time. I for one am happy companies ask about this type stuff, it's basic hygiene to keep control over your product's security, really, and the tooling really makes it a lot easier.
- pixl97 6y ago
  As someone that works for a SAST vendor I will say it's mixed. By the choices we make in what we support in languages and their dialects we can effect the ecosystem. And at the same time, I have seen some terrible things that are picked up in code the first time they are scanned, that in theory should have been obvious but were missed for whatever reason. It gets even worse when you're looking at included libraries. Also, if you're using these tools, put in requests for new features and languages. This is how we know what customers want and where to focus resources.
deleted 6y ago
[deleted]
draw_down 6y ago
Boy, this sucks. It’s absolutely correct and you can see it coming, though it didn’t occur to me before reading. Oof.
smu 6y ago
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 specific implementation. Commercial source code analysis tools have varying support depending on language (as others have mentioned: some languages are harder than others). A very valid alternative is to use a linter with security checks (and potential custom rules). The advantage will be that checking will go much faster so you can do it more often (every PR instead of nightly for example). Many security conscious companies have something like this in place. In general when you're answering security due diligence, it's your job to convince the customer you're going to keep their data safe. They will ask about certain things you don't have and it's your job to explain how you're still solving the underlying problem. Typical example: customers asking for antivirus on all systems and you using (immutable) docker containers. By the way, the interesting thing here is not the answers to the questions, but how you organise your company to quickly and effectively (as in: no follow up meetings or worse: action plans) answer them. My pet peeve here is "customer guided security": You start from what you think you need (baseline) and you add the security measures that take the longest to explain why you don't have them. That way, you're skating through most of the due diligences and sales velocity goes up, which will make your bosses very happy.
- pc86 6y ago
  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.
  - masonhensley 6y ago
raesene9 6y ago
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 product development has started. You only have to look at the rise of containerization in enterprise to see this in action. When it started tooling was way behind, and it's only catching up now, but that didn't seem to stop anyone.
- thinkharderdev 6y ago
  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.
  - raesene9 6y ago
    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.
gbrindisi 6y ago
The inverse point of view of this is that security, as everything else, is easier for stacks that are commoditized.
nuker 6y ago
I see no links between infosec and functional programming.
- goatinaboat 6y ago
  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.
  - mikorym 6y ago
    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?
    - goatinaboat 6y ago
      Also, why do you mention them specifically in the context of FP? They are mostly famous in tech circles for one day one of their interns Yaron Minsky saying, hey let's rewrite everything in OCaml. And they did, and were wildly successful, and he's the CTO now. They bet big on FP and it happened to be an excellent fit for their problem domain.
  - nuker 6y ago
    Still, no amount of FP will save your ass from someone making an internal backend service publicly accessible. Its tools like enumerating all company's public endpoints, and I wrote the tool in Python :))
ithkuil 6y ago
> 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 overhaul in the first place. The problem is that tools like vulnerability scanners address only one part of the problem; admittedly, it is a low hanging fruit.
- jcims 6y ago
  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.
  - ithkuil 6y ago
    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.
    - jcims 6y ago
      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.
k4ch0w 6y ago
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.
indymike 6y ago
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.
- maxerickson 6y ago
  What's wrong with and? Obviously you can't literally have 4 top priorities, but patient privacy isn't some dumb irrelevancy.
  - indymike 6y ago
    When you are making software that is used to make life and death decisions, privacy should not be the top priority.
    - tylerrobinson 6y ago
      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.
    - maxerickson 6y ago
      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.
deleted 6y ago
[deleted]
nautilus12 6y ago
Yeah 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
- marcosdumay 6y ago
  > Is it just because the scanners are only written small range of languages like C# or javascript? Yes. > Seems like functional programming makes for BETTER security scanning all around. Yes. > unless the scanners are just surface level and are adopted as a matter of faith Kinda. They are very useful, as they catch all those stuff that should have been designed out of the language/framework to start with. They are not something to get cracked, but they also won't discover any deep issue.
  - nautilus12 6y ago
    I feel like the underlying issue is the actual quality of the scanner doesn't matter. It's more of a liability checkbox or culpability shifting device.
deleted 6y ago
[deleted]
staticassertion 6y ago
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 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.
- HFguy 6y ago
  What do bankers have to do with SOC2? Do you mean consultants?
  - privacy-matters 6y ago
    I think he means a CPA. Certified public accountant. They are the ones who actually write the report.
- jiveturkey 6y ago
  perhaps you don't understand the way a typical company operates. security is all but ignored. SOC2 is an absolute necessity. it's a forcing function for baseline processes and controls, that 100% would not exist by default if companies were left to their own devices. for sure, i'm not talking about the 5% of competent companies.
  - staticassertion 6y ago
    Let's oversimplify things and say there are two types of companies: 1. Those who care about security 2. Those who do not care about security For the (1), SOC2 provides no value, because any structure it lends (it lends none, but you'll end up choosing some NIST thing or whatever) is something you could have implemented for much less money. Remember, you'll spend ~1 full security engineer worth of money/ time, so you could hire a FTE to just do these things. Except you won't be constrained in nearly the same ways. 2. Companies that don't care will just grift the grifters. It's simple - there are lots of easy checkboxes, and most of it is just documenting processes. Anyone who's gone through a SOC2 should see how easy it is to "game" it. It's tedious, but a large company will just hire their way out of it, and have a compliance team that's almost certainly isolated from security. Because it's gameable SOC2 is far easier for large companies to push off. They can hire a compliance team, call it 'security', and move on. Small companies, and/ or companies that care about security, are left having to dedicate their much more limited resources to compliance over implementing meaningful controls. A small company isn't going to know the many 'tricks' for doing minimal work to pass, which is a really important quality of SOC2 - you want the least policy to pass, otherwise you're setting yourself up for either stagnation or an even longer report next year, since changes between reports have to be documented and go through the process. Large companies can just get away with way more. As one simple example, let's say you have 1 FTE seceng. For compliance, they could spend N% of their time setting up logging, documenting that logging, writing docs on their IR policy, etc. Or, without SOC2, they could spend N% of their time setting up logging, writing good detections, understanding and exploring their infrastructure, documenting in a much more natural way at a lower cost, etc. And then that budget could go towards improving infra, tooling, training, new hires, etc, to do that work even more effectively. How many breaches has SOC2 stopped? Because clearly it hasn't been the deterrent in many cases - how many companies get owned, while being compliant, due to unpatched vulns (something any auditor is guaranteed to ask about)? What if they'd spent the few hundred thousand a year on a few more seceng? The way companies scale security puts ~10-500 employees to every seceng, meaning that even cutting a few would be a massive increase in risk. In short, the companies that are already ignoring security will have no problem doing so when they're large, and smaller companies, or companies that do care, will only be drained by SOC2. edit: I will also say that, * I won't state that SOC2 is universally useless. * This is a very hard problem. It's a regulation on a quality that is a very fast moving target with weak consensus.
crb002 6y ago
Blind SAST will give many false positives. It took a local megacorp a year to reduce noise on their Java build pipeline when adopting it.
peterwwillis 6y ago
Well first of all, a smaller number of tools is a good thing. Most software tools suck ass. By focusing more on a few of them, hopefully their quality will increase (depending on who is making them and what their incentives are). Second, security scanning is just part of an overall strategy for increased software quality, which helps the product made out of the software, which is the entire point of writing software. Who cares if your stack calcifies if the user has a better experience because your app crashes less, needs to be emergency-patched less often, and doesn't leak personal data like a fire hose? I am an SRE, and not a little bit of a security nerd, and I wouldn't trust myself with getting security right.
skee0083 6y ago
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.
- TheMblabla 6y ago
  Best way to stop crime is to have the state execute anyone found guilty, right? Because the justice system never makes mistakes and is always on our side! Tell me, in this utopia, is there a world government carrying out these executions? Or is it just our great country who is purging it's security experts?
- etherwaste 6y ago
  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.
finnthehuman 6y ago
>There are new forces at play which will calcify current software stacks and make it extremely hard for existing or new entrants to see similar success without a massive coordinated push backed by big enterprise companies [...] enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. The security community got exactly what they asked for. Security people were selling fear of insecurity with limited actionable advice for security to come into products/systems bottom-up, so the business has to solve it with process. Breaking into computers is fun and all, but throw around words like "risk analysis" to sound like hot shit for too long and you end up with comprehensive risk analysis process that spans beyond the bits of tech you want to play with. I work in a highly-regulated domain so software security is just another type of risk analysis we do. So shrug whatevs this doesn't calcify us more than we are already calcified. I just think it's cute that infosec people thought they were hackers, but didn't realize they're another flavor of boring business analyst telling the kids to turn down their music and develop software to their requirements.
egsec 6y ago
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).

159 points by chillax 6y ago

RajSinghLA 6y ago

Apocalypse is a strong word for a post that ends with no real prediction.

saagarjha 6y ago
It seems to me that the author is concerned that a desire for vulnerability scanning will prevent new languages from entering use because these tools won’t support them.
- bawolff 6y ago
  "Apocolypse" is still a pretty strong word for failing to break into a market because your product doesn't meet the user's requirements.
  - Rickasaurus 6y ago
    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.
    - Kalium 6y ago
      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.
      - Rickasaurus 6y ago
        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.
        Kalium 6y ago
        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.
        bawolff 6y ago
        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)

bawolff 6y ago

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 related to type theory)

iso1631 6y ago
> That's just the cost of doing business with big enterprise, certainly not a new thing. This feature is why small companies can compete with big enterprises. The big ones get the economies of scale, but they also get bogged down by being inagile.
thinkharderdev 6y ago
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.

novok 6y ago

Whee more compliance calcification that misses the point to slow down your large competitors with.

Mountain_Skies 6y ago

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 and the .net family. None of them are particularly helpful in getting this information to you. They have their marketing checklists and information deeper than this can be hard to come by from the salespeople. A few were scared of letting us have this information at all once they knew it was for a competitive analysis. That's a sign that they take a long time to support new language versions. In many companies adoption of new language versions happen organically at the developer level, often within days of the new version being released. Even if the system admins try to press the brakes a bit on deploying the new version on production servers, the pressure is there for it to happen. SAST vendors typically are not going to be able to keep pace, which will make your developers unhappy or even give them an excuse for not using the expensive tool you purchased.

zxcmx 6y ago
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.
- pc86 6y ago
  What exactly is a "'first principles' scanner?"
  - zxcmx 6y ago
    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.

jerome-jh 6y ago

Static analysis is coming to FOSS as well. There is no mystery tech behind that. Compilers actually do quite a bit of analysis: see Rust. Of course FOSS tools will probably have rougher edges, but the entire field will commoditize in the coming years. There are already a number of competing tools as mentioned by the article. The usual FP vs IP argument is not relevant: the LLVM intermediate representation is FP.

pubkraal 6y ago

The static analysis, but also software component analysis tooling are really incredibly helpful though and should really contribute to releasing stable products as well -- it's not just here to satisfy your customers management types, it's there to actually make sure your tool doesn't have 5 RCEs active at any point in time. I for one am happy companies ask about this type stuff, it's basic hygiene to keep control over your product's security, really, and the tooling really makes it a lot easier.

pixl97 6y ago
As someone that works for a SAST vendor I will say it's mixed. By the choices we make in what we support in languages and their dialects we can effect the ecosystem. And at the same time, I have seen some terrible things that are picked up in code the first time they are scanned, that in theory should have been obvious but were missed for whatever reason. It gets even worse when you're looking at included libraries. Also, if you're using these tools, put in requests for new features and languages. This is how we know what customers want and where to focus resources.

deleted 6y ago

[deleted]

draw_down 6y ago

Boy, this sucks. It’s absolutely correct and you can see it coming, though it didn’t occur to me before reading. Oof.

smu 6y ago

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 specific implementation. Commercial source code analysis tools have varying support depending on language (as others have mentioned: some languages are harder than others). A very valid alternative is to use a linter with security checks (and potential custom rules). The advantage will be that checking will go much faster so you can do it more often (every PR instead of nightly for example). Many security conscious companies have something like this in place. In general when you're answering security due diligence, it's your job to convince the customer you're going to keep their data safe. They will ask about certain things you don't have and it's your job to explain how you're still solving the underlying problem. Typical example: customers asking for antivirus on all systems and you using (immutable) docker containers. By the way, the interesting thing here is not the answers to the questions, but how you organise your company to quickly and effectively (as in: no follow up meetings or worse: action plans) answer them. My pet peeve here is "customer guided security": You start from what you think you need (baseline) and you add the security measures that take the longest to explain why you don't have them. That way, you're skating through most of the due diligences and sales velocity goes up, which will make your bosses very happy.

pc86 6y ago
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.
- masonhensley 6y ago

raesene9 6y ago

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 product development has started. You only have to look at the rise of containerization in enterprise to see this in action. When it started tooling was way behind, and it's only catching up now, but that didn't seem to stop anyone.

thinkharderdev 6y ago
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.
- raesene9 6y ago
  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.

gbrindisi 6y ago

The inverse point of view of this is that security, as everything else, is easier for stacks that are commoditized.

nuker 6y ago

I see no links between infosec and functional programming.

goatinaboat 6y ago
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.
- mikorym 6y ago
  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?
  - goatinaboat 6y ago
    Also, why do you mention them specifically in the context of FP? They are mostly famous in tech circles for one day one of their interns Yaron Minsky saying, hey let's rewrite everything in OCaml. And they did, and were wildly successful, and he's the CTO now. They bet big on FP and it happened to be an excellent fit for their problem domain.
- nuker 6y ago
  Still, no amount of FP will save your ass from someone making an internal backend service publicly accessible. Its tools like enumerating all company's public endpoints, and I wrote the tool in Python :))

ithkuil 6y ago

> 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 overhaul in the first place. The problem is that tools like vulnerability scanners address only one part of the problem; admittedly, it is a low hanging fruit.

jcims 6y ago
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.
- ithkuil 6y ago
  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.
  - jcims 6y ago
    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.

k4ch0w 6y ago

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.

indymike 6y ago

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.

maxerickson 6y ago
What's wrong with and? Obviously you can't literally have 4 top priorities, but patient privacy isn't some dumb irrelevancy.
- indymike 6y ago
  When you are making software that is used to make life and death decisions, privacy should not be the top priority.
  - tylerrobinson 6y ago
    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.
  - maxerickson 6y ago
    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.

deleted 6y ago

[deleted]

nautilus12 6y ago

Yeah 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

marcosdumay 6y ago
> Is it just because the scanners are only written small range of languages like C# or javascript? Yes. > Seems like functional programming makes for BETTER security scanning all around. Yes. > unless the scanners are just surface level and are adopted as a matter of faith Kinda. They are very useful, as they catch all those stuff that should have been designed out of the language/framework to start with. They are not something to get cracked, but they also won't discover any deep issue.
- nautilus12 6y ago
  I feel like the underlying issue is the actual quality of the scanner doesn't matter. It's more of a liability checkbox or culpability shifting device.

deleted 6y ago

[deleted]

staticassertion 6y ago

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

HFguy 6y ago
What do bankers have to do with SOC2? Do you mean consultants?
- privacy-matters 6y ago
  I think he means a CPA. Certified public accountant. They are the ones who actually write the report.
jiveturkey 6y ago
perhaps you don't understand the way a typical company operates. security is all but ignored. SOC2 is an absolute necessity. it's a forcing function for baseline processes and controls, that 100% would not exist by default if companies were left to their own devices. for sure, i'm not talking about the 5% of competent companies.
- staticassertion 6y ago
  Let's oversimplify things and say there are two types of companies: 1. Those who care about security 2. Those who do not care about security For the (1), SOC2 provides no value, because any structure it lends (it lends none, but you'll end up choosing some NIST thing or whatever) is something you could have implemented for much less money. Remember, you'll spend ~1 full security engineer worth of money/ time, so you could hire a FTE to just do these things. Except you won't be constrained in nearly the same ways. 2. Companies that don't care will just grift the grifters. It's simple - there are lots of easy checkboxes, and most of it is just documenting processes. Anyone who's gone through a SOC2 should see how easy it is to "game" it. It's tedious, but a large company will just hire their way out of it, and have a compliance team that's almost certainly isolated from security. Because it's gameable SOC2 is far easier for large companies to push off. They can hire a compliance team, call it 'security', and move on. Small companies, and/ or companies that care about security, are left having to dedicate their much more limited resources to compliance over implementing meaningful controls. A small company isn't going to know the many 'tricks' for doing minimal work to pass, which is a really important quality of SOC2 - you want the least policy to pass, otherwise you're setting yourself up for either stagnation or an even longer report next year, since changes between reports have to be documented and go through the process. Large companies can just get away with way more. As one simple example, let's say you have 1 FTE seceng. For compliance, they could spend N% of their time setting up logging, documenting that logging, writing docs on their IR policy, etc. Or, without SOC2, they could spend N% of their time setting up logging, writing good detections, understanding and exploring their infrastructure, documenting in a much more natural way at a lower cost, etc. And then that budget could go towards improving infra, tooling, training, new hires, etc, to do that work even more effectively. How many breaches has SOC2 stopped? Because clearly it hasn't been the deterrent in many cases - how many companies get owned, while being compliant, due to unpatched vulns (something any auditor is guaranteed to ask about)? What if they'd spent the few hundred thousand a year on a few more seceng? The way companies scale security puts ~10-500 employees to every seceng, meaning that even cutting a few would be a massive increase in risk. In short, the companies that are already ignoring security will have no problem doing so when they're large, and smaller companies, or companies that do care, will only be drained by SOC2. edit: I will also say that, * I won't state that SOC2 is universally useless. * This is a very hard problem. It's a regulation on a quality that is a very fast moving target with weak consensus.

crb002 6y ago

Blind SAST will give many false positives. It took a local megacorp a year to reduce noise on their Java build pipeline when adopting it.

peterwwillis 6y ago

Well first of all, a smaller number of tools is a good thing. Most software tools suck ass. By focusing more on a few of them, hopefully their quality will increase (depending on who is making them and what their incentives are). Second, security scanning is just part of an overall strategy for increased software quality, which helps the product made out of the software, which is the entire point of writing software. Who cares if your stack calcifies if the user has a better experience because your app crashes less, needs to be emergency-patched less often, and doesn't leak personal data like a fire hose? I am an SRE, and not a little bit of a security nerd, and I wouldn't trust myself with getting security right.

skee0083 6y ago

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.

TheMblabla 6y ago
Best way to stop crime is to have the state execute anyone found guilty, right? Because the justice system never makes mistakes and is always on our side! Tell me, in this utopia, is there a world government carrying out these executions? Or is it just our great country who is purging it's security experts?
etherwaste 6y ago
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.

finnthehuman 6y ago

>There are new forces at play which will calcify current software stacks and make it extremely hard for existing or new entrants to see similar success without a massive coordinated push backed by big enterprise companies [...] enterprises no longer trust their developers and SREs to take care of security, and so protocols are being implemented top down. The security community got exactly what they asked for. Security people were selling fear of insecurity with limited actionable advice for security to come into products/systems bottom-up, so the business has to solve it with process. Breaking into computers is fun and all, but throw around words like "risk analysis" to sound like hot shit for too long and you end up with comprehensive risk analysis process that spans beyond the bits of tech you want to play with. I work in a highly-regulated domain so software security is just another type of risk analysis we do. So shrug whatevs this doesn't calcify us more than we are already calcified. I just think it's cute that infosec people thought they were hackers, but didn't realize they're another flavor of boring business analyst telling the kids to turn down their music and develop software to their requirements.

egsec 6y ago

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