I have to spend a lot of time making sure these items were not an issue. But frankly speaking, this takes an ongoing effort to stay on top of. The security side of hardening servers is a huge task and much needed. Hackers are working just as hard to implant ransomware on our systems, and we have to work just as hard to avoid it. Maturity models and data warehouses are the areas I am focusing on currently. Working as a government DBA is hard, exciting, and never two days the same. If you have not tried it, think of supported 20+ unique businesses.
- Running ssms from server.
Yes, install it for emergencies, but never run it from the server unless it’s absolutely necessary.
- Backups
Not backing up databases to match rpo/rto and retaining backups for retention policies. Logs/diff between backups, dailies for a week, weekly’s for a month, monthly for a year. Excessive, yes, but needed to negate ransomware attacks.
- Standard maintenance
Not performing dbcc check database frequently can cause your backups to be completely useless. Most government offices allow a generous maintenance window, yet this is often overlooked.
- Linked servers
Offer great features but lack the performance and open the doors for security with server chaining. These should be used as needed but not left active and access rights limited.
- Hardening servers
Hardening servers is an extremely broad category and requires two things government IT departments are reluctant to allow. First, change to current practices (bad and worse) and second, open-minded thinking to improve processes.
- Patching
Frequent and timely patching servers. Checking the existence of a patch, understanding the patch fixes, and applying them at the right time (not too soon or not too late). I like 20-30 days on none security patches to be loaded, sometimes Microsoft does not fully test, or they miss an interaction, and in the wild, the patch breaks a feature you need.
- Testing patches
Having development servers for testing patches prior to patching them on production servers. I like a 20-30 day window between environment levels.
- Users with elevated privileges
All too often, government offices have servers with users that have elevated privileges that could allow harm to your databases. For example, if a key user’s account is hacked the user’s account could allow your database servers to be encrypted with ransomware or accidentally delete part of the database or the entire database.
- User maintenance
When was the last audit on users? Do they all need access still at the access level they have? Are they still employed with your agency or department?
- Starving CPU, memory, or tempdb
You need to give your servers a good balance of resources. Not enough cores, or memory, or enough tempdb specs will greatly reduce your performance and leave your users complaining that the system is SO SLOW! Tune your servers.
- Quality control checks
Check your servers for failed jobs, index performance, and entry quality.
- Mixing data with other systems for dw, pa, ml, or ai
Not making use of data warehouse (DW), predictive analytics (PA), machine learning (ML), and artificial intelligence (AI) is making your employees work 1000% harder than needed. After security issues this is the biggest area you can make improvements in.
- Using the cheapest bidder and sending data to the cloud with little or no way to access or retrieve data
Every RFPs I’ve seen that failed is because the cheapest bidder was selected, and it caused everyone involved to work harder than needed.
- Exit strategy on cloud application
You need cloud standards to manage the use of cloud services. What are your standards, entry, and exit strategies? Cloud can be good, but it has a cost. Space, compute, transfer fees all add up to the overall cost. A lot of times this is nearly or exceeds the cost of your cores for SQL server especially when you buy in the FedRAMP space that you need to be using.
- Maturity models for database
When was the last review of your progress of on improvements to your systems using something like a maturity model? Most don’t have it or use it.
- SA account
Have you changed the password? I suggest taking this further, create an account with sysadmin privileges, preferably via the active directory and then disable the SA account altogether.
- Noncomplex passwords
Often, I hear of agencies use a user of city and the password also as a city, or worse city1 as a common password on all systems and servers.
- Applications on database servers
Database servers should only have one instance on them it no applications, not even ssis, ssrs, ssdt or ssas on it. Nor should you allow vendor applications or home-grown applications on it. Window and sql server that’s it, nothing more!
- Clown cars
Servers with 60-100 databases is a problem. Limit this as much as possible however, if an application has a fixed load and users then they can combine them into one server, but do this smartly and with caution?
- Lack of tool and skills to use them
Professional tools are needed. They have a proven track record; solve issue and a help you work smarter not harder. But you will also need someone to use and manage they tools to make use of the full level of tool. They are not all crazy expensive and a lot offer discounts for government agencies.
Need help correcting any of these top 20 issues, we are here to help you? Lets get started today.
