Penny Garbus, President
Data protection has many facets. First there are hardware structures, software, and procedural processes. Then you have defensive maneuver strategies that you complete through Audit Penetration tests and Phishing tests.
You need all the different layers from many types of software and hardware firewalls, SSL certificates, then layers of security monitoring software and settings in the server hardware and networking hardware. You must ensure that all the ports, and firewall settings and procedures are in place in order to have the ability to defend through Penetration Testing and Phishing tests.
Believe it or not the data repository or container is often the last place people look to ensure their data is protected, yet it is one of the most important places to finally protect your precious commodity - data. We all know that while you have a firewall, the outside bad actors are out there and that they do find their way in through the smallest of worm holes. Yet if you do a few things in the database you can help stop them from getting your PI or Health or Financial data. They will have to close-up shop and move to a better location if you have your Disaster Recovery Processes designed, documented, and tested.
You can tell from the many horror stories in the news how data is stolen causing job loss, business closures, customers losing their information and causing havoc to life and liberty. In my next few paragraphs, I would like to summarize some strategies that you can review with your IT team whether they are consultants or employees to ensure your data is protected.
You need to know who has access to which environments, making sure employees only have access to the minimal data required to perform their job functions. Make certain that the ADMIN role is not shared and that the passwords are changed from the default passwords. Use the database tools or devops updates to show who changed what and when in the code and database schema. The production access team should be smaller than your development access team or at least better trained to review code before it is rolled up. One of the Q/A practices that is missing these days is a full standards code review prior to roll up. Roll up procedures should include testing in development, code review, recommended changes, final approval scheduled roll ups with and auditor and testers ready to test production. PLEASE do not forget in your code review to ensure a roll back plan is included and tested.
Many times, unfortunately, the bad actors are in your company. If you protect the data from inside intrusions and move outward, you will have a solid plan of protection. Make certain that you review and run scripts to see who has access in the database and run scripts to ensure that users have the proper credentials in all areas of the data from application GUI access through to the database, and firewalls and other tools. Know and limit access for every area of your environment. Run reports so you know if people that are supposed to be out are indeed out and people that need access are properly allowed in.
Then ensure that PI data, financial and health data is encrypted in the database columns, make certain that your data is encrypted at rest on the disk as well as when it is traveling, via a secure transmittal protocol.
Lastly, run proper backups. Use full and incremental so you have the least amount of data loss as possible. Ensure the backups are on completely different devices, time zones and air-gapped as well. Then test restores periodically to ensure integrity of the backup. Have a secondary environment that is not affiliated outside your always on or replicated environment ready to roll up. Back up application code, documentation, database schema, database, and the data. Update the DR plan and make certain several people know where the information is and can do the work to get your environment back up. If you have a database that is several hundred gig or in the terabytes or petabytes, then you may want to prepare an environment and run monthly full backups to it or more often to ensure you can roll up in minutes or hours and not days.
You need to validate all of these processes through audits and security penetration tests and restore tests.
In summary, your data protection plan should be written. It should be validated through testing and review and it needs to be updated and reviewed at least twice a year. Promoting this knowledge in your IT team is crucial. You don’t want a bottle neck in your DR plan to be a person or two. Once you run your penetration tests you should work to make the needed corrections and validate the corrections by running another test even it you point it just to validating the improvements that you made in the environment.
