How often do you test your databases and related applications for security flaws? Let me guess: 1) whenever you get a chance, 2) every now and then, or 3) you haven't had a chance yet. If I'm right, don't fret -- this is more common than you think. Having been in IT management and network administration positions myself, I know that it's often all you can do to keep up with the daily demands of users, developers, sales reps and so on. Security testing used to be on many IT wish lists; we'll get to it when we can. But now the unending government, auditor and business partner demands, combined with growing customer expectations to keep personal information secure, are strong-arming the average IT shop into submission.
Every network is different
It doesn't matter which security/privacy regulation your organization is up against, the requirements for performing security tests are, at best, loosely defined in all but a handful of them. Some regulations say you must perform periodic evaluations, others say "as needed" and others require testing to be performed during specified intervals.
So, do you test once a month, every quarter or once a year? What kind of testing do you do? What's really needed? I could give you the simple answer and tell you to ask your lawyer or compliance officer, but it's likely they're disconnected from the security testing process and do not really know what's required for effective security testing -- at least in this context.
There really is no definitive answer regarding your security testing parameters. It depends on your environment, your budget, management buy-in and just how much sensitive information your systems house. So, in a nutshell, what you need to focus on is testing the right systems, the right way, the right number of times. This may mean you: 1) test your externally-accessible Web applications and servers once a quarter, 2) test internally-accessible database servers twice a year, or 3) test every network sy
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
stem related to -- or in reach of -- your databases, including associated applications and underlying operating systems on every single computer. Again, there is no one good answer. Even with the same regulations, every organization's needs are different.
Test sensitive information on critical servers
During your security testing, at least look at your critical databases, applications and servers. Focusing on the urgent and important is a critical time management philosophy that translates nicely to information risk management. The sensitive information housed in your critical servers is what's being regulated and what's being targeted for attack. This type of narrow focus when testing your security will allow you to dig deep into those systems but it also takes much less time compared to testing everything (every possible network device, all workstations, unrelated applications, etc.).
The big drawback to this focus is that sensitive information is everywhere throughout your network, in every possible database and file format imaginable. It's easy to overlook gaping holes elsewhere in your environment. You can't assume you know where every byte of protected/regulated information is located and, especially, you can't assume all your organization's sensitive information is stored in safe and secure databases. If you still wish to stay focused on your critical systems, you will only know what and where to test by taking an inventory of your databases and files. This means working with others and (oftentimes) using the right tools such as those offered by Proventsure Inc., Scentric and StoredIQ Corp. to determine what's where, it's sensitivity level and how it's at risk.
Testing a specific set of systems is good, but in the end, I truly believe that the only way to find all security vulnerabilities related to your databases and critical systems is to test all your systems. Just like a home inspector looks at virtually every component -- big and small -- of a home, you need to look at all servers, all applications, all network hosts, all wireless networks and all workstations (or at least a good cross-section if you have more than a couple hundred). All it takes for someone to get in, expose information and throw your organization out of compliance with any number of regulations is a small hole on a small system. If you look at everything in-depth, you'll at least have some peace of mind and some material to CYA if/when something bad does happen. If you can't test everything now, at least have it on your radar and in your budget as a longer-term goal.
Finally, approach your security testing with a malicious eye and with good tools. That is, what can an attacker with the right skills and tools do in your environment when he: 1) is coming in through the Internet via a Web app, Terminal Services, or direct server connection, 2) has gained access to the wired or wireless network, and 3) has trusted access to one or all of your systems.
Hitting your systems from all perspectives is the only way to know for sure just how insecure your systems are. These are the basics and, at the end of the day, that's what the auditors and regulators will want to see. Not having tested everything will likely be a weak defense in a legal case -- especially if it's obvious that a breach could have been prevented with more in-depth testing.
Examine your security testing plan
In the end, what, how and when you test is a business call on your part. Just make sure security testing is taken seriously like any other business function. With all the variables, one thing's for sure -- you (and ideally your security/IT governance committee) need to come up with a plan to perform ongoing security testing, document your methodology (i.e., the steps and techniques used) and standards (i.e., tools used, testing schedule and the people responsible). Most importantly, you have to stick with it. Consistency is key. Reasonable testing and follow-up wrapped in a sustainable and repeatable process will do wonders for compliance and security. Ultimately, the side effect of your efforts will affect the business in a positive way.
[TABLE]
