There are many tools you can use to work with SQL Server and provide guidance and information about things that need attention in your systems. From best practices analyzers to classification tools, to performance management tools – there are a whole host of utilities that can help in significant ways.
However, as you’re deploying and using these tools, it’s critical to keep in place some guidance that, once you consider it, may seem like common sense. It’s not as easy as it may seem, unfortunately.
There was a great post at darkreading.com talking about the fact that when you run the data classification tool in SSMS, you could actually be helping a potential bad actor in their accessing and making sense of your systems, and not in a good way. Specifically, this tool will help you find information that may need to be protected differently, or find data elements you were not as aware of, or soft spots in your security.
The reason this can be risky is that you can also compare this against prior runs of the tool. This means the data is stored in your system and kept for reference against those future runs. This is a great help, you can make sure you are working through issues. However, it’s also a solid roadmap to the information in your systems, from critical personally identifiable information to less active security in place.
This is where you need to be very careful with the separation of powers and permissions on your systems. It’s important that this isn’t being run and maintained on your production systems, and it is important, too, that only the right people have access not only to the tool but the underlying information used to record and manage the findings.
This is true of the different audit tools you can use for your servers, for your infrastructure, for just about all of the systems that are in place for your company. It’s common practice to practice penetration tests, for example, looking for weak spots in your defenses. The results of those tests would be extremely helpful to someone looking for access points into your systems.
As you set up these tests and tools to survey and monitor your systems, take special care to also secure the results and specifics of the findings of these tests. Even the positive findings could be helpful in the wrong hands, so be sure that the right people, at the right times, have access to the right information.
Many times reporting is stored in a common “audit” location so consultants or other security and review folks can get access when needed. These resources, these system audits and review tools are not something that should be provided as a matter of course, but only as a matter of validated need.
The same could be said of providing reporting to your stakeholders and customers that may be looking for assurance on your systems. Sure, providing information to your stakeholders may show them you’re prepared and working actively to secure the environment. They may also save that report somewhere for future review or for record-keeping and at that point, you really have no control over who has access to that information. Being mindful of the lack of control of the data once it leaves your hands should drive exactly what information is shared, where, and how it is shared.
Review your systems, segregate the data, control access… as they say, “Lather, rinse, repeat.”