[AusNOG] Data Retention Solution Security Measures

[Paul Wilkins]

Eric,
When I read that Amazon, Google, Yahoo were hacked, I wonder what went
wrong, and why didn't defence in depth prevent the hack at some level. Was
it that somewhere there was a discussion about resources denied because of
concerns the solution was 'over engineered'. Remember that what's
proportionate security looks different depending on whether this is a
hypothetical exploit, or this is after the event, and you're trying to
explain (as you will be required under the mandatory disclosure laws) to
your irate customer base how a criminal syndicate now has specifics of
their address and daily routine.

DR is a very specific use case, and it is possible to ensure that read
access is not a BAU function, and that any attempt to elevate permissions
to allow read access are audited and alarmed. These measures should be
incorporated within a defense in depth framework incorporating DLP and
firewalling measures.

Kind regards

Paul Wilkins

On 6 March 2017 at 12:15, Mister Pink <misterpink at gmail.com> wrote:

> Hi Paul, true but I'm simply surveying controls in place and there is an
> additional text box for additional comments.
>
> In terms of the above approach, it sounds a little over engineered for me
> and only addresses a narrow use case, ie an attacker has already
> compromised your server, but is then unable to escalate his privilege
> enough to mount the drive as readable.
>
> It's practicality as one of a series of other controls probably depends on
> the number of warrants you need to satisfy, and the amount of data you
> collect because you would be unable to index the data,  in addition it
> raises the question of backup? - What if you pull a HDD out that has been
> offline for 2 years and it's seized?
>
> E
>
>
>
> On 6 March 2017 at 00:52, Paul Wilkins <paulwilkins369 at gmail.com> wrote:
>
>> Eric,
>> I see lots of options for securing the DR data, and defense in depth is
>> obviously all to the good. What I don't see is an option for disabling
>> reads on 1) the file systems, 2) the media. There is no operational or
>> otherwise justification for this data to be online - ever - until you get a
>> warrant. It should be possible eg. in Selinux to disable read ioctls so
>> your data is encrypt, dump, and forget.
>>
>> Kind regards
>>
>> Paul Wilkins
>>
>> On 5 March 2017 at 14:56, Mister Pink <misterpink at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> As part of un upcoming talk at AusCert in May entitled 'Look Who's
>>> Talking', I am conducting some research into the technical application of
>>> the data retention legislation across the Industry in Australia.
>>>
>>> Much has been said about the security issues surrounding the retention
>>> of this data, most notably that it is a potential  'Honey Pot' for hackers,
>>> so I am interested to understand the level of security controls that
>>> carriers have or are planning on deploying to protect the resulting data.
>>>
>>> If you have 10 minutes, I would really appreciate it if you could fill
>>> in, or alternatively forward this survey to the person within your
>>> organisation responsible for your DR Solution, and in return I will share
>>> my analysis with the respondents.
>>>
>>> https://goo.gl/forms/FKmptlZ4g4ra4jOC2
>>>
>>> All responses will be in confidence.
>>>
>>> Many thanks in advance
>>>
>>>
>>> Eric Pinkerton
>>>
>>>
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170306/c9550ab0/attachment.html>