October 20, 2015 at 4:37 pm
Mike Fal (github.com/MikeFal) did an excellent presentation to our SQL Users Group on configuring your servers using PowerShell. By having the configuration setup he was able to install a new server in 15 minutes. Not only that but it could be run over and over again so if someone changed the configuration it would change it back. I thought it might be interesting to create a nightly job that automatically ran to reset the configuration just in case.
October 20, 2015 at 4:58 pm
timlenz (10/20/2015)
Mike Fal (github.com/MikeFal) did an excellent presentation to our SQL Users Group on configuring your servers using PowerShell. By having the configuration setup he was able to install a new server in 15 minutes. Not only that but it could be run over and over again so if someone changed the configuration it would change it back. I thought it might be interesting to create a nightly job that automatically ran to reset the configuration just in case.
That's pretty cool, I'm curious how long it takes to run on a heavily customized server. You'd also have to really lock down the directory where the master script is kept. As I recall, you can compile PS, so that would make it less obvious what the program does.
It reminds me of Tripwire et al. I was reading about one called OSSEC that isn't just *NIX-based that makes me want to set up a Windows XP machine and put it in a honeypot so I can see how it gets compromised. Years ago I installed Windows 2000 for a friend who somehow really mangled his install, and he didn't have a router between his computer and his internet connection. The install was compromised before I could patch it, it was pretty amazing to see it happen. We went out and bought a copy of XP Pro and were able to patch it before it was subverted.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 21, 2015 at 6:48 am
Don't label anything the biggest breach. That's just a red flag so someone to top it, to do a bigger breach.
October 21, 2015 at 7:19 am
timlenz (10/20/2015)
Mike Fal (github.com/MikeFal) did an excellent presentation to our SQL Users Group on configuring your servers using PowerShell. By having the configuration setup he was able to install a new server in 15 minutes. Not only that but it could be run over and over again so if someone changed the configuration it would change it back. I thought it might be interesting to create a nightly job that automatically ran to reset the configuration just in case.
If someone (or something), other than the official DBA, unexpectedly changes configuration settings on the database server, then you probably want to immediately close all connections, disable all logins, alter all databases to RESTRICTED_USER mode, and begin a forensic investigation. Don't restart the server though, because you may end up losing valuable useful for the investigation.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 21, 2015 at 8:05 am
Eric M Russell (10/21/2015)
If someone (or something), other than the official DBA, unexpectedly changes configuration settings on the database server, then you probably want to immediately close all connections, disable all logins, alter all databases to RESTRICTED_USER mode, and begin a forensic investigation. Don't restart the server though, because you may end up losing valuable useful for the investigation.
I'm not up on the field of what's available in intrusion detection, but I wonder if there's the equivalent of a Tripwire-style IDS that could monitor your system databases and system tables for user databases and sound alerts if something happens. The OSSEC program that I previously mentioned can monitor your registry, so that's covered.
It wouldn't be difficult to monitor production Master, but MSDB changes with every job run so you'd need some sort of selectivity to know that most jobs are normal events.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 21, 2015 at 1:01 pm
I once worked for a company which ran Imperva appliances configured to detect any updates made by users with sysadmin permissions, so I would expect that could be useful to detect configuration changes.
Unfortunately the way it was implemented at that company was that all updates were tracked, reported upon 4-6 weeks after the event and drove the DBAs crazy as they were expected to supply an incident number for each of the updates they had made.....another example of abuse of good tech.
The beauty of it of course was that it was a tracking thing independent of the database and therefore not easy for those it was monitoring to hack.
October 21, 2015 at 2:51 pm
Wayne West (10/21/2015)
Eric M Russell (10/21/2015)
If someone (or something), other than the official DBA, unexpectedly changes configuration settings on the database server, then you probably want to immediately close all connections, disable all logins, alter all databases to RESTRICTED_USER mode, and begin a forensic investigation. Don't restart the server though, because you may end up losing valuable useful for the investigation.I'm not up on the field of what's available in intrusion detection, but I wonder if there's the equivalent of a Tripwire-style IDS that could monitor your system databases and system tables for user databases and sound alerts if something happens. The OSSEC program that I previously mentioned can monitor your registry, so that's covered.
It wouldn't be difficult to monitor production Master, but MSDB changes with every job run so you'd need some sort of selectivity to know that most jobs are normal events.
The firewall can be used to send an alert in the event of a failed connection. Also there are these things called "honeypots" where you install a dummy server (perhaps just and instance of SQL Server Express Edition) on an open port with easy passwords and some interesting (but mockup) data. The concept is that a hacker will stumble on the honeypot first, and then you watch them while they poke around.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 21, 2015 at 8:58 pm
I'm going to read between the lines on the source article.
> Until 2013, the agency had no internal IT staff with "professional IT security experience and certifications."
The scenario you'd presume is that security staff are hired with security experience and security certifications; they then liaise with all the teams of the business (active directory, networking, infrastructure, databases) to discuss what they do, what they need, throw ideas around to improve, help buy some software, draw up some best practices, and then help get it all implemented.
What I've observed instead is that people get hired through a back-rub process with no relevant experience and certifications (anyone can do security, right?). They then are not very interested in interacting with those other teams, instead spending a few years building documents that nobody follows, and purchasing expensive software not fit for purpose and which nobody uses.
So, whether they had security professionals or not doesn't matter. The calibre of them and how they do their job matters.
> Many of them were operated by agency contractors outside direct control of OPM's IT staff
This is my favourite pet peeve which is the departmentalisation cancer that is the Service Management model of IT. Rules are made on one level, ignored by competing teams at lower levels, and nobody is able, allowed, or motivated to talk to each other. They probably don't even know who to talk to.
> configuration changes require approval by the Change Control Board which meets on a regular basis. However, there are emergency situations where changes might be made outside of the CCB cycle. The recommendation for actual "technical controls" to prevent unapproved configuration changes wasn't addressed.
I'd like to propose another theory; which is that the CCB was a 2-4 week process which either ended in rubber stamping or made people want to eat a cartridge of buckshot. The technical controls weren't turned on because they'd expose that nobody followed the process, which management knew and turned a blind eye to, because they were often the ones demanding that things be implemented here and now.
This aside you need an extremely mature organisation with flexible and fluid processes to make this a positive thing which results in positive outcomes and improvements rather than a blame-shame-maim culture. That's not likely in government.
> "New technology really comes with the pricetag of changing how you do business—organizations used to have a basement with 100 really smart sysadmins, and nobody questioned how they did things.
This doesn't quite match what the article said; which was that they didn't have many admins and they weren't smart nor empowered. The problem lays with management hiring idiots and then having to wall them off so they didn't damage anything; not that they weren't micromanaging enough.
October 22, 2015 at 9:28 am
This is my favourite pet peeve which is the departmentalisation cancer that is the Service Management model of IT. Rules are made on one level, ignored by competing teams at lower levels, and nobody is able, allowed, or motivated to talk to each other. They probably don't even know who to talk to.
It also sounds much like the general operational scheme of government.
October 22, 2015 at 2:22 pm
GoofyGuy (10/22/2015)
This is my favourite pet peeve which is the departmentalisation cancer that is the Service Management model of IT. Rules are made on one level, ignored by competing teams at lower levels, and nobody is able, allowed, or motivated to talk to each other. They probably don't even know who to talk to.
It also sounds much like the general operational scheme of government.
I'll bet that back in the '80s the CIA didn't submit a list of all their agents and background to some pre-9/11 version of the 'Office Of Personnel Management'. That type of information was computerized, but it was locked away in a basement vault and guarded by MPs.
Dorks...
In retrospect, maybe the old way was the best way.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 28, 2015 at 9:10 am
...we really need to solidify and build better systems for ensuring the security of our hardware and software and preventing, or detecting, unauthorized changes...
Current cloud based deployments have moved to declarative configuration based deployments e.g. Docker. This forms part of the continuous deployment of systems. There is no tinkering with the deployed system as this breaks the ability of the hosted service to be self-managing.
This may not be suitable for some databases (hence the need for on premises databases still - amongst other reasons).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 19, 2019 at 10:49 pm
Sorry to be a pedant, but it's "breach" not "breech", unless you're talking about the risk of infiltration to your trousers/pants! Also the sentence "I'm also not sure most of us are actually getting much better at security" doesn't make any sense. The proliferation of the word "actually" in technical forums can be bewildering anyway, but surely this just needs to say "I'm also not sure how many of us are getting any better at security"
March 20, 2019 at 9:08 am
I believe that the actually probably refers to the fact that people now pay lip service to the need for security "security is a priority on our systems", while still doing sweet bugger all about it
ISV: "We need full rights on the system"
DBA: "'Full rights' isn't even a thing, specifically, what rights are the minimum required to operate your system with due regard to PoLP? <sends description and links>"
ISV: "EH? We need everything, all of them ... to connect"
or
Can you ftp us a back up of the <un-releasable by law sensitive data, subject to multi million pound breach penalties and possible criminal liability> database. Or give all connections the rights to be able to do that.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply