Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A10 - Insufficient Logging & Monitoring this is a lack of control not a vulnerability in and of itself #175

Closed
kerberosmansour opened this issue Oct 21, 2017 · 37 comments

Comments

@kerberosmansour
Copy link

commented Oct 21, 2017

A10 - Insufficient Logging & Monitoring this is a lack of control not a vulnerability in and of itself.
It is an important lack of control for sure, but a developer is not often responsible for maintaining the logs for the apps etc.. It does not create a vulnerability, it restricts and limits incident response, and investigations.

@sslHello sslHello added the A10 label Oct 21, 2017

@sslHello sslHello added this to the Top 10 2017 Golden Master milestone Oct 21, 2017

@raesene

This comment has been minimized.

Copy link

commented Oct 21, 2017

On this one I'd say that this is the Top 10 risks rather than vulnerabilities, so it makes sense to call out insufficient logging & monitoring, as it is an endemic risk with web applications and has large real-world impacts (look at the number of breaches that last for months before detection by the vulnerable organization)

@Neil-Smithline

This comment has been minimized.

Copy link
Collaborator

commented Oct 21, 2017

This one was chosen by an industry survey. 550 appsec pros picked it. I don't think that we're going to remove it.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Oct 21, 2017

Thank you @Neil-Smithline @raesene

Don't get me wrong I like that it is there, especially to look for brute-force attacks or credential stuffing not to mention looking at header logs for CSP or cert pinning and see what they are telling you.

What stood out was this issue was a lack of a passive (detection) control rather than something that would cause an increase in the exposure of a web app to security risks

My concern is with more of what has been dropped hence #177 & #174

@sslHello

This comment has been minimized.

Copy link
Collaborator

commented Oct 21, 2017

Hi @kerberosmansour,
I do think that this is one of the most important new issues that we have added to the Top10. I personally see that missing or insufficient logging & monitoring makes all other issues worse, because you might not see them at all. And you have nearly no chance to see what had happened if you need to do a forensic analysis.
Thank you very much for your question and to give us the opportunity to explain why we are happy with this community vote.
Cheers Torsten

@vanderaj

This comment has been minimized.

Copy link
Member

commented Oct 21, 2017

A. The community chose this issue to be included.

It's in. Yes it's a missing control, but it's critical when all else fails. DBIR shows why this is an important issue (>200 days to detect, most detections are external). We need to improve especially as apps move from inside to cloud, and in cloud from monolithic apps to thinks like Lambda, where there are no detection controls unless you add them in.

@vanderaj vanderaj closed this Oct 21, 2017

@drwetter

This comment has been minimized.

Copy link

commented Oct 21, 2017

@raesene

This comment has been minimized.

Copy link

commented Oct 21, 2017

Well I'd say that lack of logging & monitoring is a risk in a number of ways. Without it organisations are reliant on preventative controls which, inevitably, fail. Detective and reactive controls are required to help mitigate those failures and appropriate logging and monitoring is a key control in this area.

You only need to look at the breach reports every year and the statistics on length of time to detection to realise that in AppSec there's a serious deficit in detective controls.

Let's take your SQLi example. Monitoring could detect the successful attack and allow a SoC analyst to respond to it. Logging is extremely useful in this occasion in tracking what the attacker has done (e.g. what tools did they use, what machines did they go to next where did they exfiltrate data to).

To provide an anecdotal example, I was involved in a large breach investigation many years ago where the only reason the forensics teams had any idea what had happened because there happened to be a WAF in place in logging mode as the company were evaluating it. The initial attack vector was SQLi and that WAF provided a tonne of information as it showed the attackers uploading tools and downloading data. The information it provided was vital in speeding the analysis and clean-up from the breach.

That logging and monitoring is hard to do well is not, in my opinion, a good reason to avoid doing it, but a reason to get better at doing it :)

@drwetter

This comment has been minimized.

Copy link

commented Oct 23, 2017

@raesene I totally agree that logging is very useful and it makes sense to include it into the final top 10.

I also say this as was investigating breaches too (without WAFs), know usefulness of WAFs (and pitfalls) -- as a pure logging device (other costumers). Sure it helps resolving breaches and you probably can only shrug with your shoulders if you don't have it -- but except resolving multi-hop hacks and understanding the vector(s) to avoid next time it's still no risk to me.

V8 (it's V8 and not V7, isn't it?) in ASVS labels it as a control, too.

Way out: i.e. selling it deliberately as a control -- attention, the ice is thin here -- or explain better where the risk is. The latter is not clear enough in A10.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Oct 23, 2017

Look, I can only give my feedback to the team as has been asked the community at large, in order to help.

My feedback is that Risk = Vulnerability x Threat.
A control is meant to address a risk, this is why I feel that "Insufficient Logging & Monitoring" is one step removed from a web app risk.
You might as well add "Insufficient input validation", and include all the other insufficient controls. What then? Its the inverse of what this should be. Identity the risks, and from that you could pick the appropriate controls.

I think it is a mistake to highlight a lack of a control as opposed to web application risks.

I would also like to note that I value this control (just not in the owasp top ten).
As someone who has lead the software security program for one of the largest tech e-commerce companies, where we have installed a WAF / behavioural analytics / rate throttling in front of multi-billion dollar web properties and kept pretty detailed logs. I can tell you first hand the value of monitoring web applications, and keeping security specific web app logs.

But I can tell you we did all that effort to address real world risks, and not that we woke up one day and thought it would be a good idea since a control was missing.

I could also tell you that it hardly ever required involvement from developers, outside of providing evidence and testing that it would not break the site our impact conversion (preventing customers from purchasing). Even then it was mainly with the QA, product, sys-admins and site optimisation teams and not developers.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Oct 23, 2017

One more thing to note regardless of its initial use case most developers would hear of the OWASP top-10, because PCI specifically called it out OWASP as a best practice, it is also one of the main drivers in security teams to leverage OWASP (or SANS) due the importance of that compliance.

The control in question (6.5) says

Address common coding vulnerabilities in software-development processes as follows:

  • Train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities.

  • Develop applications based on secure coding guidelines.
    See Link

If we are adding controls which are removed from the developers writing code, we should consider the impact.

One possibility is to recommend PCI to reference another OWASP Document like the OWASP proactive controls.

@drwetter

This comment has been minimized.

Copy link

commented Oct 24, 2017

@kerberosmansour : Don't know whether you addressed me -- I am not a decision maker here. As said I believe it's not a risk too. Or if it's one it's weak.

What I am complaining about is the inconsistency, I am not a friend of that. IMO it should be either said it's a control and for reasons to be named this is an exception - which is for several reasons difficult to argue:
History of the 2017 edition, logging is named a control in ASVS - to name two.

Alternatively the risks need to be clearly named in A10.

This variable has a binary value.

@raesene

This comment has been minimized.

Copy link

commented Oct 24, 2017

@kerberosmansour I'll echo @drwetter to say I'm just a contributor offering some opinions here, not part of the core Top 10 team.

What I would say is that on the PCI side of things, I don't think the target is purely developers, but owners and operators of applications, so a recommendation for improved logging and monitoring at the application is actually very valid for that scenario as PCI has requirements for activity to be accurately logged and monitored and without application level functionality there will be a black hole in this space.

As to the consistency argument, I think there's a recognition that the Top 10 is largely an Appsec visibility document rather than a strict taxonomy and you can see that elsewhere with the overlap between A1 - Injection and A4, A7 and A8 all of which could (under some definitions of injection) be bundled up into a single issue, but the decision has been made to separate them to provide prominence to specific issues.

@drwetter

This comment has been minimized.

Copy link

commented Oct 24, 2017

@raesene , yes it's a visibility document. But there's the taxonomy in there and currently it's being sold as T10 risks

@raesene

This comment has been minimized.

Copy link

commented Oct 24, 2017

TBH thinking about it, I'm not sure why this is any different than A2 Broken Authentication and A5 Broken Access Control.

Access control and authorization are controls and lack of that control is a risk?

Logging is also a control, it's just a detective/reactive control rather than a preventative one.

So isn't A10 just calling out the lack of a control in the same way as those other two? If we say that a lacking control is a risk, then it seems reasonable to apply it to lacking detective/reactive controls in the same way we apply it to lacking preventative controls.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Oct 24, 2017

@raesene @drwetter hey guys, I could read some tension in the previous comments and that is genuinely not my intent. I wanted to articulate that a missing control is one step removed from a risk that should be in the top ten.

I am on the same page with @drwetter on the taxonomy issue.
But this is not just semantics, imagine if all the top ten was lack of controls how would it read?

@raesene one thing we could do is include this as a recommendation for individual top ten items or rephrase this as a risk. I appreciate that the problem is, this is taking place after we have created the survey etc.. which would require additional community feedback if this route is to be taken.

@drwetter

This comment has been minimized.

Copy link

commented Oct 24, 2017

@raesene

This comment has been minimized.

Copy link

commented Oct 24, 2017

Cool all :) I was just chatting as it's a topic of interest to me, the semantics of what's a risk against what's a vulnerability and how that's expressed consistently can (I think) be tricky.

I think that given that @vanderaj closed this issue 3 days ago , in the project teams mind they're fairly clear on where they're going here :)

@drwetter

This comment has been minimized.

Copy link

commented Oct 24, 2017

Sorry to be the punk here :-)

Andrew mentioned it's a control. With all due respect but the point is that this could lead to complains I rather recommend to avoid -- for sake of the top 10 and for OWASP.

If it's a control that would be also fine but we should not mention then all over the document OWASP T10 is about risks. This needs to be addressed then.

@raesene

This comment has been minimized.

Copy link

commented Oct 24, 2017

Well it's interesting you mention that, I had a similar conversation back at RC1 time.

A literal reading of it being "risks" in the traditional sense already doesn't work as several items aren't risks, they're vulnerabilities.

so XSS, XXE etc aren't risks, they're vulnerabilties, and it's been this way for a looong time, so if there's desire to fix that it would mean quite large changes in the wording of many items.

Now you could formulate wording of these vuln's strictly as risks, but it would be pretty unclear to less technical people what you were on about, and you could formulate A10 as a risk as well similarly, but again it could be unclear to laypeople what you meant.

So A10 could be "Failure to detect application layer attacks and react appropriately" so that's a risk that Logging and monitoring are an appropriate control for. But I'd kind of agree with what's been done that the wording of "Insufficient logging and Monitoring" as it's clearer.

@securestep9

This comment has been minimized.

Copy link

commented Oct 24, 2017

It is a control and it is ALREADY in the OWASP TOP 10 PROACTIVE CONTROLS as C8: https://www.owasp.org/index.php/OWASP_Proactive_Controls

If we follow this logic we should combine Injection and XSS as rename them "Insufficient Input Validation and Output Escaping" and the rest of Top 10 as "Insufficient Data Protection" - where do we draw the line?

Nobody has ever been HACKED because their application lacked logging! Yes, logging is vital to be able to detect and investigate the incident AFTER THE BREACH, but it is NOT A ROOT CAUSE of a data breach. SQLi and XSS flaws are root causes of breaches, lack of logging is not a root cause at all.

If you don't install a video camera inside your house you will not be able to record the the fact that someone opened the door and entered your house, however the lack of camera will not stop the burglar from entering your house. The burglar will enter your house and steal your valuables if your door has weak locks which can be picked with a hairpin, not because there is no video camera inside. The weak lock on your door is a root cause the intruder got in, the lack of camera isn't a root cause - it will only help to document the fact that the intruder got in.

Based on the description of the new A10 it is clear that the INTENT of it is NOT THE LACK OF LOGGING but the lack of automated attack detection and response, I quote from the text of the new A10: "the lack of active response, such as real time alerting and response activities such as blocking automated attacks on web apps and particularly APIs" - I believe we should re-phrase this item as its own description is not about logging but about vulnerability to automated attacks

@jmanico

This comment has been minimized.

Copy link
Member

commented Oct 25, 2017

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

sorry Sam. Didn't see your original mail this morning. Thx!

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

so XSS, XXE etc aren't risks, they're vulnerabilties, and it's been this way for a looong time, so if there's desire to fix that it would mean quite large changes in the wording of many items.

Rory, the terminology changed from vulnerability to (technical) risk has changed 2010. Please have a look @ p22.

@raesene

This comment has been minimized.

Copy link

commented Oct 25, 2017

@drwetter I'm not sure I follow? Is your feeling that XSS/XXE are examples of risks rather than vulnerabilties?

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

If you read it you will realize: EVERYTHING is supposed about risks here, incl. XSS, XXE.

@raesene

This comment has been minimized.

Copy link

commented Oct 25, 2017

I did read it, but still unclear how it applies to the point I was making. XSS is a vulnerability not a risk. There are risks that can arise from attackers exploiting XSS vulnerabilities for sure, but XSS isn't a risk in and of itself.

My point was , that Lack of logging and monitoring is not formulated as a risk should not necessarily preclude it from inclusion as many of the existing entries are not formulated as risks already...

Indeed the language on that page fits relatively well as it talks about the problems of weaknesses leading to risks, and Lack of logging and monitoring is undoubtedly a control weakness.

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

I did read it, but still unclear how it applies to the point I was making. XSS is a vulnerability not a risk.

XSS is a vulnerability AND a risk. A risk is composed of way more factors, see https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology .

This is the basis for the T10 since 2010.

@raesene

This comment has been minimized.

Copy link

commented Oct 25, 2017

@drwetter To quote the document you just linked

"The first step is to identify a security risk that needs to be rated. The tester needs to gather information about the threat agent involved, the attack that will be used, the vulnerability involved, and the impact of a successful exploit on the business."

From that you're suggesting that XSS is both the risk and the vulnerability?

It seems at this point that we're just debating abstract semantics of what a "risk" and "vulnerability are, so probably better to leave it here. Thanks for the very interesting discussion.

@drwetter

This comment has been minimized.

Copy link

commented Oct 25, 2017

From that you're suggesting that XSS is both the risk and the vulnerability?

yup.

Glad I could help.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Oct 29, 2017

@securestep9 @jim @vanderaj @raesene @DinisCruz @davewichers I'd like to re-open this issue due to @securestep9 feedback. As stated earlier a lack of control is one step removed from an actual web risk, and we'd like to get a consensus on this.

@drwetter

This comment has been minimized.

Copy link

commented Oct 29, 2017

@Flavioowasp

This comment has been minimized.

Copy link

commented Nov 24, 2017

I went through all of this discussion, and I could see where some of the confusion can arise.

It is very important to define and understand what is a risk, vulnerability and a threat.
A risk = A vulnerability x Threat x Impact (occurrence)

A risk (the compromise or the loss of confidential data) evaluates what are the damages when a vulnerability (for example XSS, or unencrypted data) is exploited, through a given threat (online hacker, or disgruntled employee). Here, the impact would be the measurement of the degree of damage that would take place if all the factors are realized.

Now that out of the way, OWASP Top 10 is about risks. But we know that a risk consists of a vulnerability and the threat to exploit it.

In a way, and if you think about it for a bit, the fact is that a vulnerability exists is because one or more controls were not put in place. Pick any vulnerability, and the root cause of that vulnerability is the fact that one or multiple controls are missing.

So, if we pick the lack of logging, it would constitute a vulnerability because it is based on the lack of one or more controls. If you take SQL injection, which is directly exploitable by an injection attack, the root cause of it is not injection, but rather lack of input filtering or lack of stored procedures / prepared statements. Well they all fall under the lack of controls. So, the lack of controls (enabling logging) would result in a vulnerability in the sense that attackers can do bad stuff undetected, which means it would encourage them to do so. In this case, the risk would be whatever action they wanted to achieve, such as steal your data.

I realize it is not as clear cut as SQL injection, but many vulnerabilities are not very easy to understand. For example, in a hurricane (a threat by itself) can be financially damaging (the risk) if you don’t have clear mitigation instructions (a vulnerability). As you can see, the lack of clear instructions is the vulnerability.

Other vulnerabilities would be: lack of a lack in a door, lack of a seat belt, and so on. Those are missing controls that would have prevented a threat from taking place. In those instances, the risks would be either financial, or legal, or loss of eputation for example.

I hope this clears up some points.

As far as all the domains in the Top 10, you can relate them all to having missing controls, be it broken authentication to CSRF to access to sensitive data. Therefore, they are vulnerabilities.

@Neil-Smithline

This comment has been minimized.

Copy link
Collaborator

commented Nov 25, 2017

@kerberosmansour, you stated

As stated earlier a lack of control is one step removed from an actual web risk, and we'd like to get a consensus on this.

I'm not certain why you feel we need consensus. Are you suggesting that this should not be part of the T10? There are 440 industry professionals that voted for this to be in the T10 that disagree. Removing it, besides being way too late to do that, would invalidate our methodology of using industry voting to choose 2 issues. We have strived for openness and transparency, dropping something because it feels a little different or not what we would choose seems wrong.

@kerberosmansour

This comment has been minimized.

Copy link
Author

commented Nov 25, 2017

Hi @Neil-Smithline all of this is simply feedback to help the top ten, the team are free to use it as they please. The ticket was closed a while back specifically because there was a large number of professional responses with this specific issue.

Ultimately the top ten that is data drive and the process that is open is great for the community, and we are all great full for you efforts. Getting organisations to consider application security monitoring in the SoC and their site optimisation teams is a good thing.

It might be something to consider going forward but for the OWASP Top Ten, does the team want to only accept web application security risks, or will also consider lack of controls in the top ten. Again all this is just community feedback for the team to consider as requested.

@Neil-Smithline

This comment has been minimized.

Copy link
Collaborator

commented Nov 26, 2017

We've had a lot of discussions about what the scope of the T10 should be. We couldn't come up with any clear definition that met all our needs. We finally decided that, for 2017 at least, we'd limit the T10 to CWEs. Right or wrong, that didn't seem unreasonable and is clearly defined. While you and each of us probably has a strong definition of what a "risk" is, I'd bet they don't agree. Just read the above comments - lots of differing opinions.

So "lack of monitoring and logging" is a contender for the T10 because of CWEs 223 and 778, but "insufficient active response" (from RC1) is out. We had a tough time figuring out what to do with A9 (it's not a "real" CWE - check out https://cwe.mitre.org/data/definitions/937.html). In the end we decided that A9 is important and removing it from the T10 would give the appearance that we thought it was less important. So we grandfathered it.

@Flavioowasp

This comment has been minimized.

Copy link

commented Nov 26, 2017

@Neil-Smithline : For A9, using a vulnerable software is a vulnerability by itself, because no controls were put in place to update it, fix it or address it. Similarly to A10 and many others, the fact that an attacker would realize this fact means an increased chance of a successful attack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.