RE: MS Defender for OL7 Oracle DB servers

AND (not but) using the +1 (or +n) spare physical machine policy as per MOSES, the nifty thing is to rebuild all the VMs for a physical server set and then do a swap, making the outage window approximately the same amount of time as refreshing network address widgets (if any). IF the database "instance" availability is on two or more separate sets of physical servers on which the VMs are built, this *could* facilitate true no-bounce operations, where *could* means you need to get a pant load of other things between the users and the database built to at least not prevent new logons or service requests or (harder) fail-over things in flight.

This does wreak havoc IF persistent storage media is literally plugged into the physical machine bus or backplane rather than a multi-port device or non-physically detachable device. So as usual, your mileage may vary. This is probably irrelevant to mass market solutions anyway.

It's plausible that application servers can be rebuilt to field new sessions very frequently while I tend to thing Tim's once a week goal for database servers is achievable and probably sufficient, especially if only trusted connections can be made to the database servers. If the standard environment prevents untrusted connections, then exceptions to the standard might trigger a rebuild apart from the standard schedule.

Good luck.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Monday, March 07, 2022 11:45 AM
To: oracle-l_at_freelists.org
Subject: Re: MS Defender for OL7 Oracle DB servers

Scheduled automated VM rebuilds work just fine with multi-TB databases, on-prem or in the cloud. Data storage is detached from the soon-to-be-destroyed VMs, then re-attached to newly-rebuilt VMs and binaries. Don't confuse a requirement to rebuild code and systems with a requirement to rebuild data.

Certainly there is a possibility that the very tools used for security become an attack vector; that is the whole point of the exercise, by forcing a small number of carefully scanned and trusted images to be propagated throughout. If one can't automate rebuild, then one is stuck with predominance of ever-more-fragile house-of-cards with undetected malware festering within indefinitely.

Think it through, think of alternatives, and think a couple moves ahead...

On 3/5/2022 4:33 PM, Mladen Gogala wrote:
> On 3/5/22 15:44, Tim Gorman wrote:
>> Just a heads-up as to where (I think) the world is heading...
>>
>> Years ago, I was working at a large US telecom, and one of the goals
>> of their virtualization efforts (i.e. moves to VMs on-prem, moves to
>> containers, moves to cloud, etc) is to enable themselves to rebuild
>> every virtual machine from a trusted image every week.
>>
>> If a VM becomes "infected" with anything, then that will last for
>> only a finite period before it is wiped out by a scheduled automated
>> rebuild, if it is not detected sooner and then wiped out by a
>> manually-initiated automated rebuild.
>>
>> This doesn't mean that other preventative or protective efforts are
>> reduced in any way, just that this is a last protective measure, for
>> when all else fails. And, as we know, all else will indeed fail,
>> eventually.
>>
>> Back then, they included a requirement for automated rebuild from a
>> trusted image to be scheduled every 6-9 months for all newly-built
>> infrastructure. As their skills improve, the stated plan was to
>> gradually reduce the scheduled frequency from 6-9 months down to one
>> week.
>>
>> So, if you're wondering about your organization's push to automation,
>> to virtualization, to containers, or to cloud, then it's not
>> necessarily because these things are "shiny" and "new", or somehow
>> less expensive in themselves. It is because these technologies are
>> seen as stepping stones to a possibly-as-yet-unstated goal in the
>> never-ending arms race of infoSec.
>
> Well, I am not so sure how would that function with a terabyte sized
> database in the cloud. Also, there is a very real possibility (see
> SolarWinds) that the tools used for monitoring network would be used
> as an attack vector. The only thing that can prevent the data from
> being stolen by a rogue actor acquiring access rights is encryption.
> And we don't encrypt nearly enough data. Also, phishing attacks are
> getting more and more sophisticated. The good old times of a Nigerian
> prince in need of bank transfer or "winning Microsoft lottery" are
> long gone. Acquiring credentials is easier than ever, unless MFA is
> used. The problem isn't infecting the server with anything, the
> problem is data theft. Your database server doesn't necessarily need
> to be infected with anything. The tables ACCOUNTS, CUSTOMERS and
> ADDRESSES can be dumped to CSV files using a script and the damage is
> done.
>
> Unfortunately, MS Defender doesn't do nearly good enough job to
> protect your servers. And neither does any other software. I have
> recently received several quite well crafted spear phishing attempts.
> No warning from MS Defender or McAffee. The only real defense is our
> security awareness.
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
> https://dbwhisperer.wordpress.com
> -- http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l





--
http://www.freelists.org/webpage/oracle-l