Sometimes good intentions have unintended consequences. As parents, we want to protect our children. So we shelter them, make sure they don’t play in the dirt, and keep their environment super clean. Then they grow up unable to deal with real life, allergic to everything, and afraid of life.
I know that’s an exaggeration, but I exaggerate to make a point: there are unintended consequences to our good intentions.
Case in point for security and compliances professionals: the growing number of requirements we must comply with, such as HIPAA, Sarbanes-Oxley, PCI DSS. These regulations were written and required to protect information privacy and prevent frauds, but not necessarily aligned to the technological implications of their dictates.
How do you translate information security processes that have been legislated by well-intended policy makers into actual technology solutions? It’s a tough job.
Legislative Overview from an InfoSec perspective
Sarbanes-Oxley. This was originally passed to prevent businesses from committing fraud. When we finally started seeing the first articles explaining what the law’s implications were for information technology professionals, the mandate was clear: we had to prove that the reports we generated from our systems were reliable and trustworthy.
But that was too vague. How do you translate this into technology specifications? How do we create code, architecture and technology processes to guarantee that your data is accurate and trustworthy?
There’s a very big gap there.
The Sarbanes-Oxley Act 404 helped organizations get closer to closing the legislation-technology gap. Its goal was to specify stricter technology controls on access to financial data by specifying the separation of job functions or duties.
But 404 wasn’t specific enough. It still left organizations in the dark on how to ensure their systems and applications could stand up to the type of scrutiny the Sarbanes-Oxley act requires. The good intention of clarifying the law by mandating information integrity still left a gap regarding the practical application of technology although there are more techniques and mature processes to make a robust IT and Information Security requirements and audits to close this gap.
HIPAA. The Health Insurance Portability and Accountability Act of 1996 requires health care providers and organizations, as well as their business associates, to develop and follow procedures that ensure the confidentiality and security of protected patient health information when it is transferred, received, handled, or shared.
Great act, great intentions – but as with SOX, it wasn’t created with IT in mind (that was finally resolved with the new HITECH law of 2009).
The principle enforcement mechanism to ensure the confidentiality of patient information was to require 3rd party vendors to sign a commitment form declaring that they’ll be HIPAA compliant! That was it! But how can we really ensure compliance with just a contract?
Translating Regulations Into Technology Specifications
How do you translate well-intentioned legislation into technology specifications that will keep your business from a costly or embarrassing audit (or both)?
Think about the audit process. Traditionally, an auditor would look your books and possibly other physical assets. Today, auditors require access to information systems to ensure your processes; information flows and permissions are mapped out the correct way to ensure they’re compliant.
They might find there isn’t sufficient cross-referencing of information, or that there are data leaks, or that employees with one set of duties have easy access to the information systems that should be reserved for employees with another set of duties.
Ensure your information flows and permissions are locked down. Let’s take a look at SOX: the principle mandate for information professionals specified that the data in your reports should be trustworthy. In other words, you need to guarantee your data hasn’t been tampered with.
But how do you guarantee this data integrity? By restricting access to sensitive patient or financial data to only the people whose roles it is to handle that data.
For example, we evaluated the information systems of a global financial services company to see if discrete roles and job duties were properly segregated. We had to make sure that a manager only had access to the management function, and that the DBA only had access to the database.
To our surprise we found that more than 50% of their systems were not separated into distinct user roles. The accounts payable guy was not only paying the bills, he issued the invoices and managed the database. The roles were mixed and there was danger of possible fraud. They were not compliant with Sarbanes-Oxley.
Softtek took over the process and made sure that the folks who should have access to their data really had it. We translated the requirements of the act into technology requirements, and we made sure the information would get to the right managers at the right time.
Conclusion
Translating the requirements of laws whose intentions are to make our lives better by preventing fraud and access to private data into working technology is not for the faint of heart. Many man-hours have been spent trying to specify how each law’s requirements affects IT processes, permissions and architecture. But unfortunately it must be done, because the alternatives are costly fines and possible damage to your company’s reputation.
Will we see a time when future legislation is drafted with the IT professional’s deployment needs in mind? Will legislators and bureaucrats be required to take a basic information technology architecture course?
