Whether management at your organization has bought into it or not, privacy and security compliance is here to stay, and almost every type of organization and every aspect of business is covered in some way.
Today, organizations have to comply with myriad information security regulations including:
Almost every business – large and small – is being held to higher standards of information security, and the accountability and responsibility associated with compliance is only going to increase in the future.
DBAs or network administrators responsible for database security should be concerned because the database is where most -- if not all -- of the sensitive information covered by these laws and regulations is stored. In addition, it also is the place to focus on when making improvements.
Here is what you can do to lay the groundwork for a secure database that meets compliance requirements.
Compliance essentials
Compliance may seem daunting, especially for those just starting down the path. But you can get your arms around compliance if ...
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
you approach it the right way.
Contrary to a popular misconception, database compliance is more than just a combination of a firewall, column encryption or strong passwords. Regardless, the basic compliance requirements in the database security context are likely nothing new:
- Risk assessment to determine which data is vulnerable and needs to be protected
- Authentication controls for database logins
- Access controls for database rights and administration roles
- Audit logging for tracking who did what, when, where and how
- Physical security controls to keep servers and data protected from physical threats
- Secure software development practices to stop many database and application weaknesses where they start
- Incident response procedures for recovering from hack attempts, such as password cracking, SQL injection and malware outbreaks on a network
- Business continuity procedures for responding quickly and failing over to backup systems -- or at the very least to keep your databases limping along so information is still accessible and its integrity is not jeopardized during an unexpected situation
- Ongoing testing and evaluations to find out new and known vulnerabilities present in database systems; these tests/evaluations also pertain to supporting applications and underlying operating systems and help demonstration where things stand regarding overall information risk
All of these are information security best practices, and the same basic requirements can be found in HIPAA, GLBA, PCI DSS, etc. No tricks, no magic -- just common sense stuff that should be in place to support the business.
Compliance brings these good security practices together to formalize IT processes, especially where documentation of policies and procedures are concerned.
Get going (slowly) on security compliance
For a secure, compliant database, don't try to implement widespread changes. You'll wear yourself out and anger many of your users -- not to mention the trouble you'll have finding the budget for it.
Instead, work little by little. Small, consistent improvements in database security will put an organization where it needs to be compliance-wise relatively quickly.
Start with one area, like system hardening (at both the database and operating system levels) or audit logging, and focus on that for a few months. Once a specific area is fine-tuned, move on to the next. Go down the list of what needs to be in place for compliance with the broadest set of laws and regulations. Focus to meet the highest level possible to get the best return -- on time and money.
A great way to boost your compliance efforts is to align your security practices with widely accepted standards and frameworks like ITIL, COBIT and ISO/IEC 27002:2005.
I recommend ISO/IEC 27002 because I've worked with it the longest and I like how it clearly outlines all the essential information security areas. It's not database-, application- or operating system-specific, but it doesn't need to be. It'll be a great complement to technical abilities on the database side.
The 27002 components, like most others, can be tied to database security in one way or another. The good thing is none of the laws or regulations require a specific information security standard -- you can choose which standard to use based on your organization's specific needs. It's even possible to mix and match components from the different standards to create a custom information security framework.
Do it the right way
Before moving forward, decide what is best for your organization.
A compliance/IT governance committee may already be a part of an organization. If so, this is a great start. Work with them on getting database security in line.
However, in many cases, the security and compliance burden falls into the lap of the DBA and/or network admin. If this is the case, run what you're doing by management to get their buy-in and blessing so you'll have their support later. After all, they are the people ultimately responsible.
[IMAGE]Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at kbeaver@principlelogic.com.
