Wee!, its audit time again!

I reviewed the VSI site and didn't see mention but thought I would ask here also.

Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk. That means you couldn't encrypt production files and have them usable; you'd have to decrypt, use, re-encrypt, then delete the unencrypted version; a no go save perhaps for small critical files sync'd by human usage.

And backup savesets can be encrypted, but at the cost of both increased time and the loss of compression (which is often a substantial time and space saver itself).

I presume that is still the current state of things?

I poked our pc guys to find out if the various hypervisors support running VMs whose disk files are on encrypted disks; a possible future option for a VMS 9.x VM to keep the auditors happy.

Thanks

Rich Jordan <jordan@ccs4vms.com> wrote:
>Last time I looked, VMS, even current VSI versions, can do manual per-file =
>encryption/decryption, but not whole disk. That means you couldn't encrypt=
> production files and have them usable; you'd have to decrypt, use, re-encr=
>ypt, then delete the unencrypted version; a no go save perhaps for small cr=
>itical files sync'd by human usage. =20

Right, so you go with disks that have hardware encryption. You can buy a
number of gadgets where you have to type in a number on a keypad on the disk
box before the disk becomes available to the SATA buss. This gives you the
full disk encryption the bean counters want, without any OS changes or
overhead, and without impairing the ability to move drives from machine
to machine.

>And backup savesets can be encrypted, but at the cost of both increased tim=
>e and the loss of compression (which is often a substantial time and space =
>saver itself).

Yes. There is a big CPU hit on alphas, although I would imagine it is
likely better on x86 systems where there is more mippage available.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 8/18/2022 6:50 PM, Rich Jordan wrote:
> Wee!, its audit time again!
>
> I reviewed the VSI site and didn't see mention but thought I would ask here also.
>
> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk. That means you couldn't encrypt production files and have them usable; you'd have to decrypt, use, re-encrypt, then delete the unencrypted version; a no go save perhaps for small critical files sync'd by human usage.
>
> And backup savesets can be encrypted, but at the cost of both increased time and the loss of compression (which is often a substantial time and space saver itself).
>
> I presume that is still the current state of things?
>
> I poked our pc guys to find out if the various hypervisors support running VMs whose disk files are on encrypted disks; a possible future option for a VMS 9.x VM to keep the auditors happy.
>
> Thanks
>

Fire the auditors ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 19/08/2022 03:20, Dave Froble wrote:
> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>> Wee!, its audit time again!
>>
>> I reviewed the VSI site and didn't see mention but thought I would ask
>> here also.
>>
>> Last time I looked, VMS, even current VSI versions, can do manual
>> per-file encryption/decryption, but not whole disk.  That means you
>> couldn't encrypt production files and have them usable; you'd have to
>> decrypt, use, re-encrypt, then delete the unencrypted version; a no go
>> save perhaps for small critical files sync'd by human usage.
>>
>> And backup savesets can be encrypted, but at the cost of both
>> increased time and the loss of compression (which is often a
>> substantial time and space saver itself).
>>
>> I presume that is still the current state of things?
>>
>> I poked our pc guys to find out if  the various hypervisors support
>> running VMs whose disk files are on encrypted disks; a possible future
>> option for a VMS 9.x VM to keep the auditors happy.
>>
>> Thanks
>>
>
> Fire the auditors ...
>
What difference would that make? They work from the same tick list.
Dave

On Thursday, August 18, 2022 at 6:50:39 PM UTC-4, Rich Jordan wrote:
> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk.

Whole disk encryption only makes sense where you don't have physical security of the device (i.e. mobile devices).
Data breaches come from compromised networks, in which WDE is worthless because every process on the
system has access to the disk through the key loaded in the driver at boot.

On 2022-08-18, Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>> Wee!, its audit time again!
>>
>> I reviewed the VSI site and didn't see mention but thought I would ask here also.
>>
>> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk. That means you couldn't encrypt production files and have them usable; you'd have to decrypt, use, re-encrypt, then delete the unencrypted version; a no go save perhaps for small critical files sync'd by human usage.
>>
>> And backup savesets can be encrypted, but at the cost of both increased time and the loss of compression (which is often a substantial time and space saver itself).
>>
>> I presume that is still the current state of things?
>>
>> I poked our pc guys to find out if the various hypervisors support running VMs whose disk files are on encrypted disks; a possible future option for a VMS 9.x VM to keep the auditors happy.
>>
>> Thanks
>>
>
> Fire the auditors ...
>

The auditors are there to do a job and the people running the systems
are not the people who employed the auditors.

If you can't comply, you had better have a _VERY_ good answer for why
_you_ can't when everyone else can.

You had also better have an even better answer for "In that case, why
should those VMS systems be allowed to be kept in production use instead
of being replaced with more secure systems ?"

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

David Jones <osuvman50@gmail.com> wrote:
>On Thursday, August 18, 2022 at 6:50:39 PM UTC-4, Rich Jordan wrote:
>> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk.
>
>Whole disk encryption only makes sense where you don't have physical security of the device (i.e. mobile devices).
>Data breaches come from compromised networks, in which WDE is worthless because every process on the
>system has access to the disk through the key loaded in the driver at boot.

It also makes some amount of sense in that it reduces your need to wipe
everything completely before discarding old equipment. But it's not the
wonderful thing that some security consultants believe it to be.

Some data breaches are caused by backup tapes pulled out of dumpsters and
computers purchased from surplus dealers which still contain customer data.
These aren't as popular as they once were, though.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 8/19/2022 4:18 AM, David Wade wrote:
> On 19/08/2022 03:20, Dave Froble wrote:
>> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>>> Wee!, its audit time again!
>>>
>>> I reviewed the VSI site and didn't see mention but thought I would ask here
>>> also.
>>>
>>> Last time I looked, VMS, even current VSI versions, can do manual per-file
>>> encryption/decryption, but not whole disk. That means you couldn't encrypt
>>> production files and have them usable; you'd have to decrypt, use,
>>> re-encrypt, then delete the unencrypted version; a no go save perhaps for
>>> small critical files sync'd by human usage.
>>>
>>> And backup savesets can be encrypted, but at the cost of both increased time
>>> and the loss of compression (which is often a substantial time and space
>>> saver itself).
>>>
>>> I presume that is still the current state of things?
>>>
>>> I poked our pc guys to find out if the various hypervisors support running
>>> VMs whose disk files are on encrypted disks; a possible future option for a
>>> VMS 9.x VM to keep the auditors happy.
>>>
>>> Thanks
>>>
>>
>> Fire the auditors ...
>>
> What difference would that make? They work from the same tick list.
> Dave

The question is, is that list valid? Perhaps, and perhaps not.

Some auditors might be helpful and have some good advice. But I'm currently
aware of some auditors that are basically crooks. Accepting everything auditors
might suggest may not be a good thing. And shouldn't their "suggestions" be
just that, "suggestions"?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-08-19, Dave Froble <davef@tsoft-inc.com> wrote:
> And shouldn't their "suggestions" be
> just that, "suggestions"?
>

In some cases, they are doing their audits to ensure a company complies
with required security and legal standards. In those cases, their report
is _way_ more than a "suggestion".

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Friday, August 19, 2022 at 8:19:09 AM UTC-5, Dave Froble wrote:
> On 8/19/2022 4:18 AM, David Wade wrote:
> > On 19/08/2022 03:20, Dave Froble wrote:
> >> On 8/18/2022 6:50 PM, Rich Jordan wrote:
> >>> Wee!, its audit time again!
> >>>
> >>> I reviewed the VSI site and didn't see mention but thought I would ask here
> >>> also.
> >>>
> >>> Last time I looked, VMS, even current VSI versions, can do manual per-file
> >>> encryption/decryption, but not whole disk. That means you couldn't encrypt
> >>> production files and have them usable; you'd have to decrypt, use,
> >>> re-encrypt, then delete the unencrypted version; a no go save perhaps for
> >>> small critical files sync'd by human usage.
> >>>
> >>> And backup savesets can be encrypted, but at the cost of both increased time
> >>> and the loss of compression (which is often a substantial time and space
> >>> saver itself).
> >>>
> >>> I presume that is still the current state of things?
> >>>
> >>> I poked our pc guys to find out if the various hypervisors support running
> >>> VMs whose disk files are on encrypted disks; a possible future option for a
> >>> VMS 9.x VM to keep the auditors happy.
> >>>
> >>> Thanks
> >>>
> >>
> >> Fire the auditors ...
> >>
> > What difference would that make? They work from the same tick list.
> > Dave
> The question is, is that list valid? Perhaps, and perhaps not.
>
> Some auditors might be helpful and have some good advice. But I'm currently
> aware of some auditors that are basically crooks. Accepting everything auditors
> might suggest may not be a good thing. And shouldn't their "suggestions" be
> just that, "suggestions"?
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

Most of the auditors our customers tend to get (some self hired, some because they are publicly traded) are 100% windows centric and know nothing about even the existence of other platforms, and some have gotten quite flummoxed when presented by Unix/Linux or VMS systems in those environments. I am certain this is another checkbox question; I'm trying to find out if they have the same question or actual insistence on having the windows servers run with all disks encrypted also.

My own feeling has always been its not needed on reasonably secure, non-portable systems; its just for laptops/tablets, and maybe desktops in unsecure environments. But thats just me.

So I assume I'm correct that there are no changes regarding disk encryption in VMS.

PC guru here says Hyper-V can run with the VMs VHD files on bitlocker encrypted disks, still checking on VMWare and Virtualbox. But again that's for future; right now the customer is on Integrity 2800 servers, so no go on encryption.

On Friday, August 19, 2022 at 12:07:34 PM UTC-5, Simon Clubley wrote:
> On 2022-08-19, Dave Froble <da...@tsoft-inc.com> wrote:
> > And shouldn't their "suggestions" be
> > just that, "suggestions"?
> >
> In some cases, they are doing their audits to ensure a company complies
> with required security and legal standards. In those cases, their report
> is _way_ more than a "suggestion".
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

There is also the new issue of cyber-insurance. A number of our customers are having to change their procedures in order to qualify for a cyber insurance addendum on their coverage (or standalone insurance).

On 8/19/2022 1:07 PM, Simon Clubley wrote:
> On 2022-08-19, Dave Froble <davef@tsoft-inc.com> wrote:
>> And shouldn't their "suggestions" be
>> just that, "suggestions"?
>>
>
> In some cases, they are doing their audits to ensure a company complies
> with required security and legal standards. In those cases, their report
> is _way_ more than a "suggestion".
>
> Simon.
>

I guess my question is, "who specifies required security and legal standards"?

There may be cases where external requirements exist. But if not, then isn't it
solely up to a company what they do?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/19/2022 1:23 PM, Rich Jordan wrote:

> Most of the auditors our customers tend to get (some self hired, some because they are publicly traded) are 100% windows centric and know nothing about even the existence of other platforms, and some have gotten quite flummoxed when presented by Unix/Linux or VMS systems in those environments. I am certain this is another checkbox question; I'm trying to find out if they have the same question or actual insistence on having the windows servers run with all disks encrypted also.

This is the problem. When the auditors don't know what they are doing, and
won't learn, then they demand you do what isn't reasonable.

For an auditor to work with VMS, they should know VMS very well. Would you want
a non-programmer to tell you how to write programs?

> My own feeling has always been its not needed on reasonably secure, non-portable systems; its just for laptops/tablets, and maybe desktops in unsecure environments. But thats just me.

And you are correct.

> So I assume I'm correct that there are no changes regarding disk encryption in VMS.
>
> PC guru here says Hyper-V can run with the VMs VHD files on bitlocker encrypted disks, still checking on VMWare and Virtualbox. But again that's for future; right now the customer is on Integrity 2800 servers, so no go on encryption.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/18/2022 10:00 PM, Scott Dorsey wrote:
> Rich Jordan <jordan@ccs4vms.com> wrote:
>> And backup savesets can be encrypted, but at the cost of both increased tim=
>> e and the loss of compression (which is often a substantial time and space =
>> saver itself).
>
> Yes. There is a big CPU hit on alphas, although I would imagine it is
> likely better on x86 systems where there is more mippage available.

Todays x86-64's got a lot more CPU power than the Alpha's of
25 years ago (not surprising).

But if VMS BACKUP is using AES and VMS x86-64 are able to use
the AES supporting instructions in newer x86-64's, then it will
really speed up!

Arne

On 8/19/2022 9:01 AM, Scott Dorsey wrote:
> David Jones <osuvman50@gmail.com> wrote:
>> On Thursday, August 18, 2022 at 6:50:39 PM UTC-4, Rich Jordan wrote:
>>> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk.
>>
>> Whole disk encryption only makes sense where you don't have physical security of the device (i.e. mobile devices).
>> Data breaches come from compromised networks, in which WDE is worthless because every process on the
>> system has access to the disk through the key loaded in the driver at boot.
>
> It also makes some amount of sense in that it reduces your need to wipe
> everything completely before discarding old equipment. But it's not the
> wonderful thing that some security consultants believe it to be.
>
> Some data breaches are caused by backup tapes pulled out of dumpsters and
> computers purchased from surplus dealers which still contain customer data.
> These aren't as popular as they once were, though.

That type of encryption let us call it transparent device encryption
for lack of a better word does provide some benefits, but its benefits
are often overestimated - it only helps with a few use cases.

Same with transparent database encryption.

Arne

On 8/19/2022 6:48 PM, Dave Froble wrote:
> For an auditor to work with VMS, they should know VMS very well.

To do an effective audit of VMS they would need a
good VMS checklist and auditors with some VMS knowledge.

Passing the audit with SYSTEM password being SYSTEM,
because the auditor just checked root and admin
usernames is no good.

Arne

On 8/19/2022 1:23 PM, Rich Jordan wrote:
> Most of the auditors our customers tend to get (some self hired, some
> because they are publicly traded) are 100% windows centric and know
> nothing about even the existence of other platforms, and some have
> gotten quite flummoxed when presented by Unix/Linux or VMS systems in
> those environments.

Many auditors are quite Linux capable. They have to with like
2/3-3/4 of all servers running Linux.

> My own feeling has always been its not needed on reasonably secure,
> non-portable systems; its just for laptops/tablets, and maybe
> desktops in unsecure environments. But thats just me.

I believe that is just you.

:-)

Most of the important functionality are on servers, so
to properly assess then entire solution, then auditors
need to look at the servers as well.

Arne

On 2022-08-18 22:50:38 +0000, Rich Jordan said:

> Wee!, its audit time again!
>
> I reviewed the VSI site and didn't see mention but thought I would ask
> here also.

If you have VSI support, open a support call. That'll get this
discussion added to whatever escalation and enhancement and scheduling
discussions are underway within VSI, and might also get some
documentation created and reviewed.

> Last time I looked, VMS, even current VSI versions, can do manual
> per-file encryption/decryption, but not whole disk. That means you
> couldn't encrypt production files and have them usable; you'd have to
> decrypt, use, re-encrypt, then delete the unencrypted version; a no go
> save perhaps for small critical files sync'd by human usage.

Correct. You'll need outboard encrypting storage to meet this
requirement, either as a guest in a VM that can encrypt its backing
storage, or using encrypting storage hardware.

If SSD storage hardware is involved, ensure it supports
erase-on-zero-sector writes, and also ensure that OpenVMS highwater
marking and erase-on-delete are enabled, and that no site-local $ERAPAT
service is loaded.

For those unclear on the purpose of and usefulness of full-disk
encryption (FDE) in this and other OpenVMS contexts, FDE is intended to
make server decommissioning and server repairs much less likely to leak
data, as well as cases of server or storage theft. You can't
necessarily erase a failed storage component, but somebody inclined to
try might be able to access any data remaining on the device. With FDE,
any remaining data will be inaccessible without the key.

> And backup savesets can be encrypted, but at the cost of both increased
> time and the loss of compression (which is often a substantial time and
> space saver itself).

If BACKUP is encrypting data before performing data compression, that's
a design bug in BACKUP.

Properly encrypted data is not compressible, but properly compressed
data can be encrypted.

And yes, OpenVMS systems are comparatively slow, and supported
processors prior to x86-64 are lacking in encryption acceleration
hardware features.

https://en.wikipedia.org/wiki/AES_instruction_set

While most (all?) recent x86-64 hardware does have hardware
acceleration support for encryption, I'd assume OpenVMS x86-64 is not
(yet?) using that.

> I presume that is still the current state of things?

Correct.

The OpenVMS security-related documentation—both for server management,
and for app development—is unfortunately also outdated, too.

Auditors can be difficult to deal with and can miss other issues, but
FDE and basic data security discussed here is not an unusual, onerous,
nor even remotely questionable requirement.

TL;DR: waivers and maybe FDE HW/SW support incoming.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/20/2022 1:05 PM, Stephen Hoffman wrote:

> If BACKUP is encrypting data before performing data compression, that's a design
> bug in BACKUP.

That is, unfortunately, the way it was implemented.

--

--- Rob

On 8/20/2022 1:47 PM, Robert A. Brooks wrote:
> On 8/20/2022 1:05 PM, Stephen Hoffman wrote:
>> If BACKUP is encrypting data before performing data compression,
>> that's a design bug in BACKUP.
>
> That is, unfortunately, the way it was implemented.

Would:

disallow (DATA_FORMAT.COMPRESS and ENCRYPT)

make sense?

Arne

Scott Dorsey <kludge@panix.com> wrote:
> Rich Jordan <jordan@ccs4vms.com> wrote:
>>Last time I looked, VMS, even current VSI versions, can do manual per-file =
>>encryption/decryption, but not whole disk. That means you couldn't encrypt=
>> production files and have them usable; you'd have to decrypt, use, re-encr=
>>ypt, then delete the unencrypted version; a no go save perhaps for small cr=
>>itical files sync'd by human usage. =20
>
> Right, so you go with disks that have hardware encryption. You can buy a
> number of gadgets where you have to type in a number on a keypad on the disk
> box before the disk becomes available to the SATA buss.

You named them correctly: gadgets, nothing more.

Because you've got no idea if this is actually any good. Do they actually
encrypt the data (or just do the equivalent of a shoddy bike lock?), what
algorithm and key length is used (hint: if it's just a 4 digit pin .. LOL),
are key derivation and encryption algorithms even implemented properly
(note: most encrypted systems that got broken where broken not because
the math or algorithm was attacked, but because the implementation was
bad and vulnerable)?

> This gives you the
> full disk encryption the bean counters want, without any OS changes or
> overhead, and without impairing the ability to move drives from machine
> to machine.

So everytime the machine reboots/powercycles someone has to crawl into
the broom closet (because you won't see nonsense like that in a proper
production setup) where the "server" lives and type in a number?

>>And backup savesets can be encrypted, but at the cost of both increased tim=
>>e and the loss of compression (which is often a substantial time and space =
>>saver itself).
>
> Yes. There is a big CPU hit on alphas, although I would imagine it is
> likely better on x86 systems where there is more mippage available.

Pretty much any modern amd64 machine has the AES-NI extensions which
effectively drops the overhead of AES encryption to almost zero.
An Intel Core i5-3570K @ 3.40GHz can do aes-xts with 512 bit keylength
at 1.3 GB/s, an Intel Xeon E3-1245 v5 @ 3.50GHz can do the same at
1.8 GB/s - both encrypt and decrypt (just checked with
'cryptsetup benchmark').

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Scott Dorsey <kludge@panix.com> wrote:
> David Jones <osuvman50@gmail.com> wrote:
>>On Thursday, August 18, 2022 at 6:50:39 PM UTC-4, Rich Jordan wrote:
>>> Last time I looked, VMS, even current VSI versions, can do manual per-file encryption/decryption, but not whole disk.
>>
>>Whole disk encryption only makes sense where you don't have physical security of the device (i.e. mobile devices).
>>Data breaches come from compromised networks, in which WDE is worthless because every process on the
>>system has access to the disk through the key loaded in the driver at boot.
>
> It also makes some amount of sense in that it reduces your need to wipe
> everything completely before discarding old equipment. But it's not the
> wonderful thing that some security consultants believe it to be.
>
> Some data breaches are caused by backup tapes pulled out of dumpsters and
> computers purchased from surplus dealers which still contain customer data.
> These aren't as popular as they once were, though.

That's why a large company I know mandates full disk encryption on
_all_ systems. And yes, the backup tapes are also encrypted. This allows
one to "delete" a backup set by just wiping the keys. All backup sets
on that tape are deleted - now you can reuse the tape.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Dave Froble <davef@tsoft-inc.com> wrote:
> On 8/19/2022 4:18 AM, David Wade wrote:
>> On 19/08/2022 03:20, Dave Froble wrote:
>>> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>>>> Wee!, its audit time again!
>>>>
>>>> I reviewed the VSI site and didn't see mention but thought I would ask here
>>>> also.
>>>>
>>>> Last time I looked, VMS, even current VSI versions, can do manual per-file
>>>> encryption/decryption, but not whole disk. That means you couldn't encrypt
>>>> production files and have them usable; you'd have to decrypt, use,
>>>> re-encrypt, then delete the unencrypted version; a no go save perhaps for
>>>> small critical files sync'd by human usage.
>>>>
>>>> And backup savesets can be encrypted, but at the cost of both increased time
>>>> and the loss of compression (which is often a substantial time and space
>>>> saver itself).
>>>>
>>>> I presume that is still the current state of things?
>>>>
>>>> I poked our pc guys to find out if the various hypervisors support running
>>>> VMs whose disk files are on encrypted disks; a possible future option for a
>>>> VMS 9.x VM to keep the auditors happy.
>>>>
>>>> Thanks
>>>>
>>>
>>> Fire the auditors ...
>>>
>> What difference would that make? They work from the same tick list.
>> Dave
>
> The question is, is that list valid? Perhaps, and perhaps not.
>
> Some auditors might be helpful and have some good advice. But I'm currently
> aware of some auditors that are basically crooks. Accepting everything auditors
> might suggest may not be a good thing. And shouldn't their "suggestions" be
> just that, "suggestions"?

That depends. Any credit card processor who deems the PCI DSS rules to
be mere suggestions will eventually (usually rather quickly) discover
that it doesn't have a business anymore.

Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

On 8/21/2022 9:54 AM, Alexander Schreiber wrote:
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 8/19/2022 4:18 AM, David Wade wrote:
>>> On 19/08/2022 03:20, Dave Froble wrote:
>>>> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>>>>> Wee!, its audit time again!
>>>>>
>>>>> I reviewed the VSI site and didn't see mention but thought I would ask here
>>>>> also.
>>>>>
>>>>> Last time I looked, VMS, even current VSI versions, can do manual per-file
>>>>> encryption/decryption, but not whole disk. That means you couldn't encrypt
>>>>> production files and have them usable; you'd have to decrypt, use,
>>>>> re-encrypt, then delete the unencrypted version; a no go save perhaps for
>>>>> small critical files sync'd by human usage.
>>>>>
>>>>> And backup savesets can be encrypted, but at the cost of both increased time
>>>>> and the loss of compression (which is often a substantial time and space
>>>>> saver itself).
>>>>>
>>>>> I presume that is still the current state of things?
>>>>>
>>>>> I poked our pc guys to find out if the various hypervisors support running
>>>>> VMs whose disk files are on encrypted disks; a possible future option for a
>>>>> VMS 9.x VM to keep the auditors happy.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>> Fire the auditors ...
>>>>
>>> What difference would that make? They work from the same tick list.
>>> Dave
>>
>> The question is, is that list valid? Perhaps, and perhaps not.
>>
>> Some auditors might be helpful and have some good advice. But I'm currently
>> aware of some auditors that are basically crooks. Accepting everything auditors
>> might suggest may not be a good thing. And shouldn't their "suggestions" be
>> just that, "suggestions"?
>
> That depends. Any credit card processor who deems the PCI DSS rules to
> be mere suggestions will eventually (usually rather quickly) discover
> that it doesn't have a business anymore.
>
> Kind regards,
> Alex.
>

Credit card processing is not just protecting your data, thus being a bit different.

A while back we came up with a design to protect credit card data, checking
account data, and such. Basically breaking up the data, and storing pieces in
different databases, on multiple servers, encrypted. Thus all the information
was not in one location. Might get pieces, a tad more difficult to get a
complete piece of data.

Regardless, had to transmit the data at some point in time, so that exposure is
constant.

Then we took a look at the third party vendors who would store, and protect, the
data, AND take all responsibility. It was a no-brainer, we abandoned all plans
to store the data ourselves.

Back to auditors. Would not a reasonable person/company determine whether a
prospective employee was qualified for a job? Then why would not a reasonable
person/company do the same for auditors? But all too often that doesn't happen.
If an auditing firm could show reasonable knowledge about VMS, then they might
be qualified to perform auditing on a VMS solution.

That just doesn't happen very often ...

Human intelligence is a myth ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 8/21/22 11:33, Dave Froble wrote:
> On 8/21/2022 9:54 AM, Alexander Schreiber wrote:
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 8/19/2022 4:18 AM, David Wade wrote:
>>>> On 19/08/2022 03:20, Dave Froble wrote:
>>>>> On 8/18/2022 6:50 PM, Rich Jordan wrote:
>>>>>> Wee!, its audit time again!
>>>>>>
>>>>>> I reviewed the VSI site and didn't see mention but thought I would
>>>>>> ask here
>>>>>> also.
>>>>>>
>>>>>> Last time I looked, VMS, even current VSI versions, can do manual
>>>>>> per-file
>>>>>> encryption/decryption, but not whole disk.  That means you
>>>>>> couldn't encrypt
>>>>>> production files and have them usable; you'd have to decrypt, use,
>>>>>> re-encrypt, then delete the unencrypted version; a no go save
>>>>>> perhaps for
>>>>>> small critical files sync'd by human usage.
>>>>>>
>>>>>> And backup savesets can be encrypted, but at the cost of both
>>>>>> increased time
>>>>>> and the loss of compression (which is often a substantial time and
>>>>>> space
>>>>>> saver itself).
>>>>>>
>>>>>> I presume that is still the current state of things?
>>>>>>
>>>>>> I poked our pc guys to find out if  the various hypervisors
>>>>>> support running
>>>>>> VMs whose disk files are on encrypted disks; a possible future
>>>>>> option for a
>>>>>> VMS 9.x VM to keep the auditors happy.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>> Fire the auditors ...
>>>>>
>>>> What difference would that make? They work from the same tick list.
>>>> Dave
>>>
>>> The question is, is that list valid?  Perhaps, and perhaps not.
>>>
>>> Some auditors might be helpful and have some good advice.  But I'm
>>> currently
>>> aware of some auditors that are basically crooks.  Accepting
>>> everything auditors
>>> might suggest may not be a good thing.  And shouldn't their
>>> "suggestions" be
>>> just that, "suggestions"?
>>
>> That depends. Any credit card processor who deems the PCI DSS rules to
>> be mere suggestions will eventually (usually rather quickly) discover
>> that it doesn't have a business anymore.
>>
>> Kind regards,
>>             Alex.
>>
>
> Credit card processing is not just protecting your data, thus being a
> bit different.
>
> A while back we came up with a design to protect credit card data,
> checking account data, and such.  Basically breaking up the data, and
> storing pieces in different databases, on multiple servers, encrypted.
> Thus all the information was not in one location.  Might get pieces, a
> tad more difficult to get a complete piece of data.
>
> Regardless, had to transmit the data at some point in time, so that
> exposure is constant.
>
> Then we took a look at the third party vendors who would store, and
> protect, the data, AND take all responsibility.  It was a no-brainer, we
> abandoned all plans to store the data ourselves.
>
> Back to auditors.  Would not a reasonable person/company determine
> whether a prospective employee was qualified for a job?  Then why would
> not a reasonable person/company do the same for auditors?  But all too
> often that doesn't happen.  If an auditing firm could show reasonable
> knowledge about VMS, then they might be qualified to perform auditing on
> a VMS solution.

Of course at the level where the decisions are made (and the auditors
contracted) your demand for VMS knowledgeable auditors is just more
ammunition to throw VMS out the door and go with something more in line
with modern business practice.

bill