tag:blogger.com,1999:blog-13756280.comments2024-02-08T03:44:23.780-08:00Jeremiah GrossmanJeremiah Grossmanhttp://www.blogger.com/profile/05017778127841311186noreply@blogger.comBlogger3729125tag:blogger.com,1999:blog-13756280.post-10717629949202800062020-12-21T14:56:42.953-08:002020-12-21T14:56:42.953-08:00What a great story! Thanks for sharing!What a great story! Thanks for sharing!CunningPikehttps://www.blogger.com/profile/01571709322147364965noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-45149685953514393172018-09-01T09:01:05.004-07:002018-09-01T09:01:05.004-07:00Very well thought out. The relevance of today'...Very well thought out. The relevance of today's media is definitely 'questionable' at best, yet there are very few options to pay for actual content relevant to what you're interested in following without this third party influence. A required element for the next-generation media is not only to provide paid content by the subscriber, but also to NOT accept payment from interests looking to push a product/agenda/narrative to those subscribers. Without this, or some similar restriction, content providers will just be taking money from subscribers in addition to what they've already received from the pay-to-play influencers. Most newspapers and magazines under today's model already suffer from this, and aren't worth sending money to add more profit to their existing model. <br /><br />I think there are people that want and would pay for content like this (like myself), but not under the current model that allows for these kinds of deceptive practices. Mike Andersonnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-6108052477393167032018-07-17T23:59:06.514-07:002018-07-17T23:59:06.514-07:00100% agree. You would know better than anyone.100% agree. You would know better than anyone.Markhttps://www.blogger.com/profile/13843509641085137668noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-61972390679754712992018-05-13T16:59:55.437-07:002018-05-13T16:59:55.437-07:00Maybe think of a different use case. Imagine a sce...Maybe think of a different use case. Imagine a scenario where company A plans to acquire company B which has web properties with major vulnerabilities. Even these vulns have not yet been exploited (in the real-estate case, no foundational/fire damages have occurred yet) perhaps company B, like in what the real-estate industry does, needs to fully disclose all the "section 1 or section 2 issues"? It can be mandatory (by cyber insurance policy) for the seller to disclose and fix all major exploitable vulnerabilities before the transaction can go through. Verizon could have been better off for their Yahoo! acquisition had there been a "Section 1 form".Sichao Wanghttps://www.blogger.com/profile/14496438641278746003noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-49084322093734373142018-05-12T15:43:48.703-07:002018-05-12T15:43:48.703-07:00Part two:
Anyways, YES "If we really want t...Part two: <br /><br />Anyways, YES "If we really want to push forward our collective understanding of application security and increase the value of our work, we need to completely change the way we think. ". <br /><br />And YES YES YES "if your position is recommending that the business should fix each and every vulnerability immediately regardless of the cost, then you’re really not on the side of the business and you will continue being ignored." So many times YES. <br /><br />I find myself explaining over and over to people "is your goal really to find all the bugs? fix them all? and do that all before they go into production? Then you're high." But stated this way no one says, "yes that's the goal". So then that leads very naturally into the next point which is, ok then you have to assume you have vulnerabilities in your production code at all times correct? Answer "yes". Then why are you not obsessed with getting visibility into where your attackers are attempting to breach your code so that you can know if one of those vulnerabilities is being breached or someone is at the very least attempting to do so? Answer "cause I didn't think to do that". We should do our best to find and solve as many vulnerabilities as we can but we have to assume we can't find them all and then production attack visibility and protection are paramount. On top of all that, many attacks against apps are now not even trying to find bugs. They're exploiting features through unintended use cases or misuse or abuse of application functionality. Functionality that doesn't even get picked up in sast or dast (which is another reason why I'd prob say bug bounty or pen test is ultimately more valuable). <br /><br />Long response but just really resonated with how I've been thinking and talking about appsec recently. And makes me wonder how long security testing in its current carnation will last. (spoiler is prob forever which is sad but doesn't mean we can't make progress one by one).Anonymoushttps://www.blogger.com/profile/07147634173070513305noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-67479964519334842252018-05-12T15:43:28.900-07:002018-05-12T15:43:28.900-07:00Ah, there's approving queue. Ok I'll post ...Ah, there's approving queue. Ok I'll post the second part now and hope you can figure out how to make them line up. Sorry J. Anonymoushttps://www.blogger.com/profile/07147634173070513305noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-23761975498037695462018-05-12T15:42:06.442-07:002018-05-12T15:42:06.442-07:00Great article Jeremiah. And I have a ton of though...Great article Jeremiah. And I have a ton of thoughts but in general, have been thinking along very similar lines. A quick question and some extended thoughts <br /><br />What do you think about pen tests and bug bounties? Are they better than DAST even though the output is still focused on lists of bugs and to get as many as you can? The upside is at least they're typically putting in the work to show executability.<br /><br />I've been finding myself telling security people this story often recently. The whole job of appsec historically has been to create lists of bugs and pass them to the developers. But what is the developer's experience of getting the lists of bugs? They say "you didn't have to buy a tool or pay a pen tester to tell me I have bugs in my code. I have tons of bugs filed against my code base and most of them are hindering important business functionality. So why should I care about these bugs compared to those ones? These are all just theoretical risks, not actual ones." Basically we think making longer lists of bugs are somehow doing our jobs better at appsec. But is a lack of bugs really the problem? Absolutely not. The problem is prioritizing those that actually matter. I know I'm speaking to the choir on this but thought I'd share how I've been explaining the same thing you laid out above to folks. <br /><br />The follow-on point is one that you refer to a couple times above. So DAST is better than SAST and you say "where they’ll eventually be found by DAST and/or exploited by attackers." The "and/or exploited by attackers" bit is the key we've found to change the story here with both how we prioritize and how we get devs to give a shit in the first place. This also ties in with the equation for the risk you talk about later on (probability (of breach) x loss (expected) = risk.). So how do you actually get this information? Our take is a mix of both understanding from REAL ATTACK DATA on your apps both where attackers are attempting to attack and being able to see when they're actually having success in an attack is crucial to being able to calculate the probability of breach part. If you can see all your attack traffic and understand what parts of your app it's focused on, then you can start numerically building an informed sense of the probability of breach. The real attack data also completely changes the conversation with devs because the attack is no longer a theoretical game nor is it something that you've paid someone to find in their code. It's an actual attacker attempting to breach their code as you speak with them. This leads devs to actually care to pay attention to the data in the first place and makes it much easier to have the infosec to app dev manager discussion each quarter about what parts of the code base you should be proactively hardening (the ones with the highest risk, aka high loss and highly targeted by attackers). <br />Anonymoushttps://www.blogger.com/profile/07147634173070513305noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-2085507493588120372018-05-11T06:09:26.458-07:002018-05-11T06:09:26.458-07:00One report you might be interested in is the Techn...One report you might be interested in is the Technical Assessment Methodology (TAM) in development by the Electric Power Research Institute (EPRI) that performs a bounded analysis of components to assess and mitigate vulnerability. The attack surface characterization of an asset in the TAM focuses on the critical data and what means exist to interact with it. They avoid the boondoggle of chasing innumerable vulnerabilities by looking at exploit sequences comprised of attacker objectives, attack pathways, and attack mechanisms and identifying what residual vulnerabilities are not covered by the applied security control methods.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-18159390907945037872018-05-09T13:11:13.707-07:002018-05-09T13:11:13.707-07:00I didn't see mentioned the requirement to unde...I didn't see mentioned the requirement to understand the risks associated with the application itself. What kind of information is it handling? What happens to the business if the app is not available and for how long due to an attack or breach? What are the compliance requirements associated with the application and their implications to customers? I learned long ago that if you can't bring the assessment into meaningful terms to the business and align with business risks then all you are doing is creating a report for its own sake which in many cases will be ignored.Anonymoushttps://www.blogger.com/profile/16158362747019221218noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-73892543033795578912018-05-08T08:06:18.299-07:002018-05-08T08:06:18.299-07:00But wait... thinks are actually worse. Some of the...But wait... thinks are actually worse. Some of the DAST-found and even VA-found infrastructure vulnerabilities also "don't matter" (= do not lead to loss). The challenge is that most don't know what do. Unlike in advertising (“Half the money I spend on advertising is wasted; the trouble is I don't know which half.” ), my fear now is that in vulnerability management 80% of the money is wasted, but nobody knows which 20% matter....Anton Chuvakinhttps://www.blogger.com/profile/12740087457147758558noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-37869359039538059102018-05-07T18:19:26.197-07:002018-05-07T18:19:26.197-07:00"My question is, you're going to produce ..."My question is, you're going to produce a bunch of SAST findings... but what is the likelihood for each of those findings will be found, exploited, and lead to material business loss by a real adversary? If low, why do we bother? If high, I'd really like to see the data to back it up. "<br /><br />If you are asking about us specifically - for the most part we have to assume at least a subset of any particular class of vulnerability will bite us, because of both the volume and skill of adversaries. Would a particular SQL Injection on some obscure page actually be found and exploited if we let it through? Probably not. But if we allowed SQL Injection at any volume into our code bases a very non-trivial amount of it would be exploited and we would be on fire from it. Its not terribly feasible to speak of the likelihood of a particular instance of a vulnerability being exploited by an attacker, but we do know that when the density/prevalence increases, the likelihood we will be exploited does as well (which is reasonably obvious, but still). There are other factors that get figured into it (platform mitigations, what attackers seem to be looking for at a given point, if there is blood in the water around a certain scenario, etc.), but keeping the bug density low is one of the few elements that a dev team has to control their likelihood of exploitation. <br /><br />A really good analogy is inoculation rates in the field of epidemiology - the chance of a measles outbreak is almost entirely tied to the vaccine level. The chance increases substantially with each % below 97%. Can a doctor tell if a specific person not getting vaccinated will be involved in the outbreak - certainly not - but when they look at the population in aggregate they can talk about outbreak chances pretty accurately. So given that we know our population of code will be exposed to constant attempts at exploitation, our best predictor is how prevalent a vulnerability is within that population. <br /><br />If you weren't asking the question of us specifically, I think that everything I saw above is true for companies in general EXCEPT that their population of code might be exposed to attempts at exploitation far less regularly. Using the above analogy, we don't vaccinate against smallpox anymore because nobody gets exposed - if that ever changed, the fact that the vaccine rate is essentially 0 we would be very screwed. In the epidemiology world risk is the combination of vaccine rate and rate a population would be exposed to a pathogen. In our world its probably looseley bug density combined with rate a codebase faces scrutiny by attackers. Higher the scrutiny, the lower your density needs to be to survive. Lower the scrutiny, the more tolerance a company can have for high bug density - hence me thinking most companies, by virtue of having lower scrutiny, are probably fine focusing on high accuracy critical findings (and really solid patching in common platforms on their attack surface)Joshbwhttps://www.blogger.com/profile/01597375484321975241noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-43562036454045235662018-05-07T15:54:27.805-07:002018-05-07T15:54:27.805-07:00@Joshbw: Thank you for the response! "You dra...@Joshbw: Thank you for the response! "You draw the conclusion that the 85-95% of SAST vulnerabilities that don't overlap with DAST are in categories 1-3." Actually, no. The categories were possible theories as to why so many vulnerabilities in general go unexploited -- however they are found. Not so much those being reasons for why SAST doesn't find what DAST does and vice versa, which you nicely articulated and without any argument from me. In general though, let's say we take your environment and way you do testing, which is completely fine. My question is, you're going to produce a bunch of SAST findings... but what is the likelihood for each of those findings will be found, exploited, and lead to material business loss by a real adversary? If low, why do we bother? If high, I'd really like to see the data to back it up. <br /><br />Effectively, I think we essentially touched on the same answer in your second comment. I just wish we had actual data to back up our thinking, rather than simple judgment calls that we can't justify!Jeremiah Grossmanhttps://www.blogger.com/profile/05017778127841311186noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-77713831786684230882018-05-07T13:39:24.541-07:002018-05-07T13:39:24.541-07:00Though to your larger point - I'd say that *mo...Though to your larger point - I'd say that *most* applications (those without serious adversaries in their realistic threat model) should probably only run high accuracy checks for critical vulnerabilities - dangerous deserialization, SQL injection, etc. (basically the "run code on your server infrastructure" or "run code in most end users' DOM" checks), and the state of tooling makes that scenario a pain to do. Will most applications ever be attacked (outside of wormable scenarios), probably not, but ensuring that you don't have the critical issues is sort of like making sure your buildings have fire escapes - fires are rare, but you still want to be prepared because the results are catastrophic if you aren't.Joshbwhttps://www.blogger.com/profile/01597375484321975241noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-4503448901932747222018-05-07T13:11:55.514-07:002018-05-07T13:11:55.514-07:00You draw the conclusion that the 85-95% of SAST vu...You draw the conclusion that the 85-95% of SAST vulnerabilities that don't overlap with DAST are in categories 1-3. While my experience doesn't necessarily map to any other enterprise (we don't run out of the box security rules, for reasons you cite plus several others, instead opting to write our own rules), our code bases are large enough that I would call my experience a lot more than anecdotal. And that experience is that the lack of overlap is for several reasons:<br /><br />1. DAST, for scenarios where it has some feasible way to map the interactive surface of a piece of code (e.g. Web UI, swagger defined services, etc.), still requires a lot of baby sitting to get anything approaching reasonable coverage, and on anything but trivial apps is never 100%. And there are apps where DAST feasibly could map the surface, but rarely does so effectively (Electron and Cordova apps, for example). SAST gets far more coverage with much less manual intervention, so we have more rules for SAST<br /><br />2. The categories in #1 are the minority - the closest DAST gets for an out of the box solution for a whole boatload of app/service models is fuzzing, and that still requires a ton of manual work to get decent coverage. Given that DAST is either a manual or non-existent option for many project types, we have similarly invested in more rules for SAST<br /><br />3. DAST tests are miles away from comprehensive. Even a slight variation from a standard exploit scenario stymies most DAST. It simply isn't adaptive like a human is, nor is it capable of tying together several inferential clues (though some DAST attempts this by reporting a ton of low quality "informational" findings). The state of DAST is that it can tell you if you are obviously exploitable, but some of us are protecting against adversaries that will invest the time into finding the unobvious exploits. At the end of the day, static analysis with a good taint flow engine (or control flow for certain issues) is simply much more accurate (for both false positives and false negatives) across a larger swath of code types than the current state of DAST at finding exploitable (not vulnerable - actually exploitable) scenarios, so we have invested more in SAST rules <br /><br />4. Writing new DAST tests is a lot more labor intensive than writing tests for (good) SAST offerings<br /><br />5. DAST is operationally much more expensive to run than SAST, which has informed where we invest in rule authoring<br /><br /><br />None of those things means that the mismatch between SAST and DAST rules is because of points 1-3. That said, as I copped to initially, we aren't indicative of the average experience given our threat model and resources to customize what we run (a whole lot of rules in both commercial SAST and DAST are absolute garbage, so anyone running the out of the box experience likely hates it). However, I think its a mistake to say that if a rule is in SAST but not DAST that its one of your first three categories of issues<br />Joshbwhttps://www.blogger.com/profile/01597375484321975241noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-75228838932398613212018-03-28T08:48:15.410-07:002018-03-28T08:48:15.410-07:00Hi, Jeremiah, nice to hear from you. Wishing you g...Hi, Jeremiah, nice to hear from you. Wishing you good luck with the new venture.Mark Kerznerhttps://www.blogger.com/profile/13141058882531144922noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-23920878381350321272018-03-28T07:37:30.666-07:002018-03-28T07:37:30.666-07:00Hard work is no accident. Congrats you guys. Hard work is no accident. Congrats you guys. Anonymoushttps://www.blogger.com/profile/14140477758380269208noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-10750948506564662552018-03-27T14:54:42.218-07:002018-03-27T14:54:42.218-07:00Would like to see what you've done. How do I ...Would like to see what you've done. How do I get an invite?Anonymoushttps://www.blogger.com/profile/10181795992376025671noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-38145716684198567562018-03-27T11:26:00.249-07:002018-03-27T11:26:00.249-07:00Bravo!Bravo!Anonymoushttps://www.blogger.com/profile/14732020554475151272noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-16499614586933669432018-03-27T11:05:47.745-07:002018-03-27T11:05:47.745-07:00Congratulations! Truly a missing piece of the App...Congratulations! Truly a missing piece of the AppSec puzzle. Markhttps://www.blogger.com/profile/13843509641085137668noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-6075802152204376062018-03-27T08:55:59.462-07:002018-03-27T08:55:59.462-07:00Congrats! I remember when Outside Intel was a side...Congrats! I remember when Outside Intel was a side project coupla servers in RSnake's house. Glad to see it finally be leveraged for something awesome.Planet Heidihttps://www.blogger.com/profile/07887831060071362491noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-37516126762890132642017-07-07T12:57:44.302-07:002017-07-07T12:57:44.302-07:00What about adding an X-Frame-Option header?
https:...What about adding an X-Frame-Option header?<br />https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-OptionsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-44586557289193988602017-04-18T15:45:07.884-07:002017-04-18T15:45:07.884-07:00I think you're right to say that the ad tech i...I think you're right to say that the ad tech industry created the problem...but doesn't that also point to the solution, too?<br /><br />Advertising worked as a revenue stream for hundreds of years before ad tech was a thing. It depended on relationships directly between publishers and advertisers, so there was a level of trust upfront, and the volume of ads was smaller when you weren't just fed them by a broker, so vetting individual ads was possible. I see no fundamental reason that couldn't continue to work in the digital space. It may not be what the advertisers want, and is certainly not what ad tech wants, but it seems to be the most tenable route forward.Andrewnoreply@blogger.comtag:blogger.com,1999:blog-13756280.post-26274559185919726752017-02-01T18:25:03.704-08:002017-02-01T18:25:03.704-08:00Hi people,
Thank you so much for this wonderful a...Hi people,<br />Thank you so much for this wonderful article really!<br />If someone want to learn more about <a href="http://betabulls.com/" rel="nofollow"> Finding A Technical Cofounder </a> I think this is the right place for you!<br />Anonymoushttps://www.blogger.com/profile/17532112687067702445noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-10502071495741157892016-12-22T13:16:40.396-08:002016-12-22T13:16:40.396-08:00People are getting in contact with the savagest of...People are getting in contact with the savagest of hackers Amir Hagay at theblackhatcreator000@gmail.com or you could text him on +18283677582 to help them predict the stock market,clear student loans,expunge criminal records,upgrade university grades,bank accounts and other debts,fix credit ratings,double your tax return and help hack business competitors as i and my family are a witness...contact theblackhatcreator000@gmail.com You need a savvy hacker though,one who would be able to <br />carry out and successfully execute hacks on your behalf while keeping it all discrete and under the radarAnonymoushttps://www.blogger.com/profile/07635210739286805273noreply@blogger.comtag:blogger.com,1999:blog-13756280.post-61931230565545068122016-12-20T22:07:38.679-08:002016-12-20T22:07:38.679-08:00Please continue this great work and I look forward...Please continue this great work and I look forward to more of your awesome blog posts.<br /><a href="http://www.brassetravel.net/travel/getting-the-most-out-of-concierges-in-dubai.html" rel="nofollow">dubai</a><br />johnnyhttps://www.blogger.com/profile/01915780128741556109noreply@blogger.com