Think like a security admin instead of programmer. You are right that dynalloc
is not a problem but to a security admin, it is an exposure. Exposures combine
to become a problem. Here are some examples (UNRELATED to dynalloc) that may
help to clarify.
1. Don't you have customers that refuse to send in dumps? Thankfully most
customers are willing but technically they are an exposure.2. Can an outsider
(without userid / password and no anonymous) use FTP to access files? In the
Target breach, they successfully found userid's and passwords.3. Securid cards
are strong password validation compared to simple passwords yet they still
aren't a standard practice.4. Are strong SAF dataset rules sufficient to
protect data? Of course not. Several of the SAF classes exist because dataset
rules are not enough. 5. Can a great security admin fully protect a system? No.
It's always about compromise and balance. In general, it works out well but it
still has exposures.
> If a user can access data, the data should be considered exposed
Exactly. As a security administrator, this is the compromise. For whatever
reason, it's worth the risk and we try to find alternative methods to reduce
that risk.
Jon.
On Sunday, December 24, 2017 5:59 AM, Peter Relson <[email protected]>
wrote:
The argument that dynalloc is the problem strikes me as somewhat dubious.
It was suggested that you need to restrict dynalloc because an allocated
data set is a way to capture data that the user is already authorized to
access.
That is not the "problem" statement; a data set might contribute to the
possible bandwidth of an attack but it does not make the attack possible.
If a user can access data, they can extract it in many ways (including
writing it on a piece of paper).
If a user can access data, the data should be considered exposed, to the
extent that you do not trust the user.
Peter Relson
z/OS Core Technology Design
