19

I recently noticed a penetration test report wherein the non-compliance of the European Union (EU) cookie law was stated as a finding under an "other" category. I consider this more of a legal, privacy-related matter and not so much security.

Why would this be in a penetration test report? Are there possible security-related concerns that I'm not aware of?

David
  • 15,814
  • 3
  • 48
  • 73
Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
  • 6
    How was the scope of the penetration test defined? Or in other words: Is a finding like this acceptable within the defined scope? – Tom K. Feb 12 '18 at 11:54
  • The scope was quite clear "...finding vulnerabilities, weaknesses, and other security-related issues in IT systems on a few IP addresses and domain names...". So according to my own interpretation, this finding is only acceptable when I'm not aware of the security concern of not being compliant with the EU cookie law. – Bob Ortiz Feb 12 '18 at 12:00
  • 24
    I personally know of no security issue that results out of this. It was probably more of a nice-to-know finding for you (or the client), that's probably why it was under "other". – Tom K. Feb 12 '18 at 12:08
  • @KevinMorssink is the issue that a banner/pop-over allows you to say 'no' to the tracking/cookies/etc.... and then the site continues to track you? – New Alexandria Feb 12 '18 at 13:58
  • 35
    "_finding vulnerabilities, weaknesses, and other security-related issues_" If the use of the cookie was/is in non-compliance with EU law, it could leave you vulnerable to prosecution. I see no reason for it _not_ to be in a pen-test report (unless specifically excluded). – TripeHound Feb 12 '18 at 14:59
  • 3
    @TripeHound To be fair, that wording heavily suggests that they are talking about _security_ "vulnerabilities and weaknesses". Being liable to prosecution from EU regulations isn't a security vulnerability, it's a legal vulnerability. Not to say I'd argue about being given that information; but it still does sound questionable that aligning with EU regulation is relevant to their security. – JMac Feb 12 '18 at 18:52
  • 7
    @TripeHound If you're going to interpret the words that widely, then "Tracy hasn't had a 'flu vaccine" is a vulnerability and "James can only bench-press 30lbs" is a weakness. – David Richerby Feb 12 '18 at 19:30
  • This is an excellent question, and if rephrased well could be used as part of an evaluation regarding whether a security organization will provide competent reports. – New Alexandria Feb 13 '18 at 04:26
  • 1
    The "5 Whys" come to mind here. There are possibly deeper organisational / compliance issues around "why" the banner was missed. – Joe Stevens Feb 13 '18 at 12:19
  • 3
    @David Going bankrupt due to some exceedingly high fine, might conceivably be seen as a valid DOS attack? ;) – Voo Feb 13 '18 at 13:42
  • It's in the report because the reviewer wanted to show his usefulness and squeeze in as many "problems" as possible. What's next - reviewing your ToS to see if they comply with EU laws? – JonathanReez Feb 13 '18 at 18:27
  • 1
    @DavidRicherby If we were going for a comprehensive security assessment and resources were infinite, I'd expect Tracy's lax vaccinations and James' frailty listed, because there *are* corner-cases where those might play a role in security, since security is a wholistic cross-cutting concern. But because resources are finite, we optimize: for the "availability" aspect of security, Tracy's vaccinations are a small risk and hard to check, while "wide open to legal prosecution by several wealthy nation-states or class-actions by their citizens" is non-negligible risk and trivial to check. – mtraceur Feb 13 '18 at 19:13

4 Answers4

35

I don't know of any technical security impact relating to not adhering to EU cookie laws.

Ultimately I think this is mostly down to the discretion of the assessor and the context of the assessment. Privacy issues are security-adjacent and come with similar PR impacts, and may even be judged to infringe upon the rights of the individual, so I think in some cases such findings may be useful.

For me the question isn't so much whether these things should be reported to the client, as whether or not they should be in the pentest report itself. There are other communications channels that can be used to relay this information. It may well be that this was discussed and the client asked that it be put into the report. It could even be that compliance concerns were one of the key drivers to having the assessment done in the first place. Some scopes explicitly include looking for findings that might embarrass the company or its associates (content injection is a fun one here).

I have reported everything from functionality problems to typos (albeit serious ones with vulgar consequences) to clients when doing pentesting work, when appropriate, because ultimately my job is to help improve their system. I don't think it hurts to include this kind of thing in a report because it can always be removed and filed separately at the client's request.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 3
    The "technical security impact" is that the user's data is being retained and utilized in a way they have indicated they do not allow. Just because you do not consider it as dangerous as login credentials being at-risk does not mean that privacy != security. – New Alexandria Feb 12 '18 at 14:14
  • 3
    @NewAlexandria : To be precise "... in a way they have not indicated they allow". It is much more likely that the website is failing to ask permission to store cookies than that the website has asked, been denied permission, and is doing it anyway. – Martin Bonner supports Monica Feb 12 '18 at 14:23
  • 1
    @MartinBonner when the user is in the EU, the site cannot implicit track even though the user has not been given the ability to indicate their preference. – New Alexandria Feb 12 '18 at 14:32
  • 4
    @NewAlexandria : Yes I know that. However there *is* a difference between "indicated they do not allow" and "not indicated they allow". Legally they have to be treated the same, but morally (and when it comes to sentence), they are different. – Martin Bonner supports Monica Feb 12 '18 at 15:19
  • 1
    It occurs to me, you may not be a native English speaker. "indicated they do not allow" is "forbade"; "not indicated they allow" is "not (yet) actively permitted" – Martin Bonner supports Monica Feb 12 '18 at 15:21
  • 1
    Native speaker here; we are just using (and/or confused by) the specificities involved. To use your term: _morally_, if I have not yet permitted (i.e ambiguous), then doing so is forbidden. I would say "do unto others.." but, alas, I don't know if you mind that [something forbidden to me] is done to you. – New Alexandria Feb 12 '18 at 16:15
  • @NewAlexandria no forbidden, in the word itself is past tense - a person did, in the past, forbid you from doing something. One cannot by inaction forbid something. – Tim Feb 12 '18 at 23:18
  • 2
    @Tim: "One cannot by inaction forbid something." - If it's forbidden by a law and users rely on the assumption that the website adheres to that law, does it still take each user to get active individually and repeat stating explicitly that they disallow said tracking? – O. R. Mapper Feb 13 '18 at 06:51
  • 1
    I would like to point out that this comment chain is turning into a tangential discussion involving semantics and the pronoun game: "they" in "they do not allow" could mean "the user in the EU as an individual agent/actor does not allow", and "the EU as a collective entity, which is in philosophical principle supposed to be an agent/actor representing the combined/consensus interests of the people within its jurisdiction". There's also copious unstated philosophy/ethics stuff entangled at the foundation. TL;DR: maybe move to chat? – mtraceur Feb 13 '18 at 19:21
14

A vulnerability is something that leaves you open to the possibility of being harmed. Being prosecuted or sued for violating the law is a form of harm. Therefore, not complying with the law is a vulnerability. It really is this simple.

David Schwartz
  • 4,203
  • 24
  • 21
  • 1
    Quoting from ISO27000: "*vulnerability*: weakness of an asset or control that can be exploited by one or more threats". "*threat*: potential cause of an unwanted incident, which may result in harm to a system or organization". Including being prosecuted or sued seems like a bit of a stretch to me. – Tom K. Feb 12 '18 at 15:35
  • 3
    The question is whether it is appropriate to be in scope in a pentest report. – schroeder Feb 12 '18 at 16:38
  • 3
    @TomK. being sued could harm the organization, particularly if it's a legitimate lawsuit - I don't see how that's much of a stretch – user2813274 Feb 12 '18 at 17:25
  • 3
    @TomK. You don't think a lawsuit or government investigation is an unwanted incident which may result in harm to an organization? – David Schwartz Feb 12 '18 at 18:57
  • The wording OP used in comments was "finding vulnerabilities, weaknesses, _and other security-related issues_ in IT systems" (emphasis mine). This implies that they are looking into vulnerability of _security related systems_; not of their compliance with regulations. It's not clear to me how failing to comply with the law is a security vulnerability. – JMac Feb 12 '18 at 18:57
  • 3
    @JMac Security is the state of not being vulnerable to threats. Threats are potential unwanted incidents that expose you to harm. Bluntly, this is absolutely basic stuff and it's very hard to tell if you're being serious. To me, as a security professional, this question is shocking. – David Schwartz Feb 12 '18 at 18:58
  • @DavidSchwartz So your security department is responsible for making sure your entire organization is up to date on all legal practices? "Vulnerable to threats" is an exceptionally vague term. I imagine that is there is sexual harassment in your workplace, IT security is not responsible to mitigate the threat and vulnerability it could expose your company to. It doesn't really seem clear to me how a regulation-compliance issue (that is based around user transparency) would fall under the category of "security vulnerability". – JMac Feb 12 '18 at 19:09
  • 1
    @JMac compliance and security are very closely related and in many organizations legal and security teams fall under the same department, or at least answer to the same executives. IT security in particular won't be responsible for ensuring compliance to all regulations, but it would be at least partially responsible for ensuring compliance to the _technical aspects_ of regulations. With this understanding it is not a stretch to offer include the cookie compliance (technical regulation) info on the same report. – Mr.Mindor Feb 12 '18 at 20:45
  • @Mr.Mindor So then this currently doesn't answer the question. They stated the extremely broad definition of vulnerability. There's no explanation how that connects to IT security vulnerabilities, or why this should be considered one. I made the example that sexual harassment would be considered a vulnerability; because there could be legal action brought against the company for it. Doesn't mean they should consider it part of IT security. I'm not saying this necessarily shouldn't be; but this answer doesn't give any strong support for why it should be. – JMac Feb 12 '18 at 20:56
  • 3
    @JMac Yes, they are. They work with compliance and legal as necessary. IT is responsible for detecting and mitigating threats that have an IT component, as compliance with cookie-handling regulations does. I can't imagine offhand a sexual harassment issue with an IT component, but if there was, IT would be partially responsible for responding to it. – David Schwartz Feb 12 '18 at 21:30
  • @DavidSchwartz Considering that most communication these days is electronic, the overwhelming majority of all sexual harassment likely has "an IT component" (as does the overwhelming majority of all business activity). While I think there's clearly a distinction to be drawn here - anything to do with browser cookies clearly needs to be at least partly the responsibility of the IT department, since most of the rest of the organisation probably doesn't even understand what they are - I think you're still making overly broad strokes, just as JMac says. – Mark Amery Feb 13 '18 at 00:50
  • 3
    @MarkAmery If a penetration tester found evidence of sexual harassment during their testing, I would definitely expect them to report it as a vulnerability. Frankly, I would be horrified if they ignored it and would never employ that firm again. As I said, it's a vulnerability because it leaves you open to the possibility of harm. Whose responsibility it is to address that vulnerability is not the penetration tester's responsibility to determine. (Of course failing to detect such a vulnerability would be excusable. Failing to report it if discovered is not.) – David Schwartz Feb 13 '18 at 01:28
  • 1
    I'm sorry, but this whole discussion is pointless. When agreeing to conduct a penetration test, client and contractor also agree on the scope of that pen test. Typically said scope includes finding and reporting vulnerabilities found in assets and controls to the client. If it also includes reporting legal issues - which it doesn't in OP's case - then you can include it, if not, then don't. If I were a pen tester, I wouldn't want to work for a client with a scope like that, because I'm probably a pen tester, and not also a lawyer. – Tom K. Feb 13 '18 at 08:04
  • @TomK. The scope determines what tests they perform, it should not determine what is a reportable result. Again, any penetration tester who found an actual vulnerability and did not report it as a vulnerability would be a penetration tester I would never employ again. – David Schwartz Feb 13 '18 at 17:51
  • Actually both is defined within a scope of a pen test. You have to limit the type and amount of "reportable findings" or else test results will get convoluted and unreadable. Again: this is not a vulnerability. It is something a pen tester *can* report to a client, but probably on another channel. – Tom K. Feb 13 '18 at 17:57
8

This is a security issue for the users.

Non-compliance of cookie-related laws includes that cookie data is being built about you while on the site, after you have clicked 'opt-out'. If the site does not acknowledge the GDPR (privacy laws) then some degree of personal identifying information about the user is being leaked into the site's domain, stored, and used in ways that amount to tracking. This includes:

  • if a banner pops-up saying that cookies are being used and "click OK to accept"
  • if no notification is made to the user, but tracking is performed
  • if no option nor preferences are given to the user, yet tracking is performed.
  • and others

Cookies are one obvious thing to test for, and it is perhaps the only reliable way to test for tracking, since backend techniques would be invisible unless a specific personalization feature remains consistent across pageviews

For some corp's that I have been part of, some lawyers argue that cookies are not illegal as long as they do not connect session data with a personal identifier.

Regardless, this would be a likely vector for errors or misrepresentation, and thus I would expect it to show up in a report dealing with user security.

tl;dr: people don't seem to understand user privacy is a security issue for the user.

New Alexandria
  • 270
  • 1
  • 9
  • 2
    Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/73067/discussion-on-answer-by-new-alexandria-the-non-compliance-of-the-eu-cookie-law-a). – Rory Alsop Feb 13 '18 at 09:16
0

Non-compliance to the law means that the site must be fixed. The GDPR in particular is not an "optional" law where you can accept the fines for a breach.

So it is likely that the site must be fixed. But the GDPR deadlines are tight. Many companies have realized that they need to start early. For others, like this case, it will be a rush job. And the experience with rush jobs is that at best you get what's requested. So here, last-minute changes to the site may not go through extensive security review as GDPR compliance takes precedence.

As an example, the GDPR gives customers the right to review their own data. A rushed implementation may give customers the right to review other data, including company-sensitive data and data from other customers. That is a definite security issue. Therefore, the need to hurry with GDPR compliance is correctly identified as a risk factor.

MSalters
  • 2,699
  • 1
  • 15
  • 16
  • Another good dimension on an apparently-subtle issue – New Alexandria Feb 12 '18 at 16:42
  • 6
    Why do answerers keep mentioning GDPR? The GDPR is not the "EU Cookie Law" - that's the ePrivacy directive. The [EU's page on cookies](http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm) doesn't even mention the GDPR. I freely admit that I have close to zero knowledge of these laws, but as far as I can see this answer simply has no relevance that to the question that was asked. If I'm wrong, explaining how the GDPR (or, frankly, anything to do with actual user privacy) is relevant to the cookie law would help clarify why. – Mark Amery Feb 12 '18 at 18:29