Re: [TLS] network-based security solution use cases

[Flemming Andreasen <[e-mail]>]

On 11/7/17 7:01 PM, Stephen Farrell wrote:
> Hiya,
>
> On 07/11/17 23:27, Flemming Andreasen wrote:
>> Thanks for taking an initial look at the document Stephen - please see
>> below for responses so far
>>
>> On 11/7/17 4:13 AM, Stephen Farrell wrote:
>>> Hiya,
>>>
>>> On 07/11/17 02:48, Flemming Andreasen wrote:
>>>> We didn't draw any particular line, but the use case scenarios that we
>>>> tried to highlight are those related to overall security and regulatory
>>>> requirements (including public sector)
>>> I had a quick look at the draft (will try read properly en-route to
>>> ietf-100) and I followed the reference to [1] but that only lead to a
>>> forest of documents in which I didn't find any reference to breaking
>>> TLS so far at least. Can you provide an explicit pointer to the
>>> exact document on which that claim is based?
>> For NERC, you can look under  "(CIP) Critital Infrastructure
>> Protection". CIP-005-5 for example covers the electronic security
>> perimeter, which has a couple of relevant requirements and associated text:
>>
>> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States
>>
> Thanks for that.
>
> So I didn't see any mention of TLS in that document at all.
Correct - the document is not a technical protocol specification but 
rather provides a set of requirements that have to be satisfied.
>> To be clear though, the document does not specifically call out breaking
>> TLS, but it does clearly call out the need to detect malicious inbound
> For inbound (on page 9) I see it mentions IDSes and application
> layer firewalls as examples yes. Given that the latter would not
> require any messing with TLS at all, this seems to be a very
> clear example of a regulation not requiring breaking TLS. That'd
> mean there is no regulatory requirement at all wouldn't it?
An application layer firewall (aka NGFW these days) does indeed require 
you to be involved with TLS. How would you perform application-level 
inspection without ? Example functions include scanning for malware 
downloads, URL/application filtering, attack signatures (getting a bit 
more into the IDS space).


> But again, if there are real regulatory requirements there that
> really do call for MitM attacks on TLS I'd be glad to look at them
> if you want to quote them.

Again, the document is not a technical protocol specification, but it 
clearly describes the notion of an electronic security perimeter with a 
need for electronic access point and provides IDS/IPS as example 
instantiations of such a function. Let me quote a bit more from said 
document:
<quote>
/The standard adds a requirement to detect malicious communications for 
Control Centers. This//
//is in response to FERC Order No. 706, Paragraphs 496-503, where ESPs 
are required to have two//
//distinct security measures such that the BES Cyber Systems do not lose 
all perimeter protection//
//if one measure fails or is misconfigured. The Order makes clear that 
this is not simply//
//redundancy of firewalls, thus the SDT has decided to add the security 
measure of malicious//
//traffic inspection as a requirement for these ESPs. Technologies 
meeting this requirement//
//include Intrusion Detection or Intrusion Prevention Systems (IDS/IPS) 
or other forms of deep//
//packet inspection. These technologies go beyond 
source/destination/port rule sets and thus//
//provide another distinct security measure at the ESP./
</quote>

I don't know how you can reasonably argue that you satisfy the 
requirement here if you don't inspect encrypted traffic.

>> and outbound communications by leveraging an "Electronic Access Point"
>> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter.
> Personally, I have to say I find the outbound stuff nonsense.
> I know people make money selling product and services for that.
It's not nonsense - it's deployed for a reason and it actually blocks a 
lot of attacks, in no small part by disabling command and control 
traffic. WannaCry and HeartBleed are just two of the more prominent 
examples of this, and there are many more where they came from (some 
encrypted, some not). You may want to take a look at 
http://blog.talosintelligence.com/2017/05/wannacry.html and 
http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html 
for starters. Feel free to browse around for many more.

>>> I'd also claim that your reference to PCI-DSS is misleading, as that
>>> same spec also explicitly calls for there to be good key management
>>> specifically including minimising the number of copies of keys, so
>>> at most, one might be able to claim that PCI-DSS is ok with people
>>> who break TLS in a nod-and-a-wink manner. But if you do have a real
>>> quote from PCI-DSS that calls for breaking TLS then please do also
>>> send that (it's been asked for a bunch of times without any answer
>>> being provided so far).
>> I will need to look more closely for such a quote - if anybody else
>> knows of one, please chime in as well.
> It's been asked for a number of times without any substantive
> response. I would assume that one of the authors of this would
> be able to point at the text that caused you to add in a mention
> of PCI-DSS. If not, that seems odd.
>
> I actually looked through the PCI spec myself and found that it
> is fairly explicitly asking for good crypto and not bad crypto.
> (E.g. as mentioned, saying to minimise the number of copies of
> keys that are anywhere.)
Let's take the PCI-DSS part on the parallel part of this thread.

>
> Maybe the ADs ought liaise to some of those organisations and
> ask them if they do or do not recognise the claims related to
> breaking TLS being attributed to them?
I think that's a really good suggestion.

Thanks

-- Flemming

> Or even better, maybe just not making those claims would be
> easier all around and more accurate.
>
> S.
>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Thanks,
>>> S.
>>>
>>>
>>> [1]
>>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP
>>>
>>>
>>