Richard Mackey offers expert advice on frameworks that can help security pros find their compliance and regulatory needs, and most importantly, meet them.
Read the full transcript from this video below: Building a framework-based compliance program
What I'll be talking about today is building a compliance program. This presentation is all about assembling your compliance requirements, actually capturing your state, and giving yourself grades so that you understand exactly where you stand, as far as your compliance. Building a compliance program that allows you to cycle through various aspects of measuring, achieving, and determining whether your compliance objectives are appropriate. Then finally, achieving compliance, both in the short-term and in the long-term.
Compliance with any regulation at all, whether it's a regulation, a contract, or a standard requires a process. The elements of this process are, first, understanding what your goals are; understanding exactly what parts of different regulations, contracts, or standards need to be complied with and how they apply to your organization. The next is choosing appropriate metrics. What that means is that you need to determine exactly how much you need to do as your organization to actually achieve compliance. The next is to follow a consistent approach; that means in two dimensions consistent from department-to-department and from one assessment to another. The two dimensions are across your organization and in time. The next item is to establish realistic expectations for the progress you're going to make in achieving compliance. One of the problems that we see organizations face often is that they decide that they're going to comply with some regulation or standard, and then it takes them a certain amount of time to achieve that compliance; but they've made statements about when they're going to achieve compliance prior to really understanding what it's going to take to achieve that compliance.
Which leads me to my next item, which is ensuring discipline and the organizational commitment it takes to make sure that you achieve compliance continuously from year-to-year-to-year. What happens in a lot of organizations is that they can have their focus changed and taken away from compliance by interesting projects like the latest product that they need to deal with. Then what happens is they fall out of compliance and it becomes very difficult to bring themselves back into compliance.
The two things that I really think you should take away from this presentation are that compliance, like all of security, is a process; it's not project and it's not a product. It's not a set of technology you can deploy and immediately achieve compliance. It's something that needs to be baked into your everyday business. The next is what your drive for compliance should include good security. Good security leads to compliance, where compliance may not necessarily lead to good security. What you should have is all of your driving factors achieving better security, which would then leading to compliance.
The first thing that you need to do when you're trying to establish what you need to do to achieve compliance is to understand what your compliance requirements actually are across the board. There are many possible compliance objectives; some might be regulatory. For example, if you're a public company, you need to comply with Sarbanes Oxley, or you're a financial company and you need to comply with Gramm-Leach-Bliley for privacy measures. If you're an organization that handles sensitive health information, you need to comply with HIPPA. If you're a bank, you might need to comply with FFIEC regulations. Aside from regulations, however, there are also other types of requirements that organizations sometimes miss. For example, there are contracts that you've established with partners or you might have a contract with industry association, like the payment card industry that you need to comply with. Those are contractual requirements that you should assemble in the same way that you do any other regulatory requirements that you need to meet. Then there are other areas that you might establish as requirements for yourself, like standards of practice; ISO 17799, or COBIT, a governance framework. What you need to do, though, is look at all the requirements across the board and assemble them so that you understand which ones will be dealt with through common processes, common mechanisms, and common policies.
To chart your course through the maze which is compliance, the first thing you need to do is understand your regulatory requirements. That means establishing and assembling the regulatory rules and how they would be interpreted for you in your business, for an organization of your size. The next thing you need to do is outline what the scope for compliance is. What system and processes would be affected by this particular regulation, again, in the context of your organization? Then you need to look at the risks in your world, in your business, and determine what controls need to be in place to mitigate those risks. If you look at all the requirements associated with a particular regulation, then you have to look at what the risk of not meeting those requirements would be, and then establish controls that could allow you to mitigate the risks and meet those requirements. One of the places that's really useful to look for control objectives in particular practices is to look at standards like ISO 17799 and COBIT, to establish a set of control objectives that you can then use to meet the requirements of a given regulation, for example.
The next thing you need to do is establish metrics. What I mean by metrics is that you need to determine what level of a particular practice you need to meet to be considered compliant. Where you can look at is previous audits as a guide. If an auditor told you that you were not meeting the requirement, or conversely, if they told you that you were meeting your requirement, you can use that as your metric. If you're unsure about how much you need to do, you can enlist professional help. You can go to consultants and other auditors and ask them to help you understand what current industry practices are and establish some audit guidelines to understand how good you need to be in a particular area. The last step is to document you control objectives so that you know what level you need to achieve. Then you can communicate that to all the divisions that need to correspond or need to actually meet these requirements.
Given those metrics and those controls, you need to document them. Then you need to review the state of your practices, compared to the required controls. What that means is actually conduct an assessment and give yourself a report card to determine where you have achieved compliance, where you fell short of compliance, and whether you're not compliant, at all. In some cases, there may be even some controls that aren't necessary and don't apply to you at all, so you can knock them completely off the list. The important part is that you need to document why each area was judged to be compliant, partially compliant, or non-compliant. Because it turns out that as time goes on, something that was judged to be perfectly adequate in today's business environment might not be adequate later. That's why you have to capture not only that you were compliant, but why you were judged to be compliant so that you can address . . . you might have to strengthen those controls at a later date. Then after this done, after you have a sense of where you comply and where you don't comply, you need to assemble the list of places where you weren't compliant and assign a priority to each one so that you know which ones to tackle first.
One other piece of advice that I'd give you is that you need to order that list by priority. You need to establish which ones are the most important, then look for roots causes that can help you nail more than one requirement, or more than one deficiency, at one time. Examples of these types of activities might be having a risk assessment process in place. Making sure that you understand what kinds of information, in gross form or in relatively coarse form, your organization deals with and how sensitive the pieces of data are. Once you understand how sensitive certain data sets are, then you can determine how you should handle them. Then you can build training programs so that you might be able avoid certain compromises because certain types of information were exposed. The other piece that you want to look for, after you've look for some core and causal parts of your organization that you've dealt with, is look for some easy ones as well, so that you can check-off some items and achieve green in more items so that you can actually have a good progress report to give your management.
One of the interesting areas of compliance, if you look at all the various standards that are out there, the regulations, and even codes of practice or frameworks that you can use, is that all compliance requires the same sort of cyclical process. It doesn't matter where you look; it all has the same structure. For example, the first part is that you want to look at the information that you need, that you actually deal with: Who owns it? Who cares for it? Who uses it? How sensitive is it? That's the information; those are the goods that you really need to protect. Next you need to analyze your risks to determine what the risks are to that data, whether it's a risk of confidentiality, integrity, or availability. Then once you understand the risks in the information, you need to apply controls to mitigate those risks for the various pieces of information.
After you've established certain mechanisms, whether those are policies, processes, or technical controls, you need to measure whether they've been effective and actually effective at mitigating risks. Then determine whether you need to adjust them over time once you've judged them to be ineffective. If they've been ineffective for the previous period, then you need to adjust and strengthen them. What you do is repeat this process over and over again, every year let's say, so that you can make sure that your compliance activity is actually improving over time.
If you look at ISO 20701, COBIT, COSO, HIPPA, or FFIEC, they all have the exact same process. In fact, here's an example of a process that's in a NIST guide for HIPPA compliance. It's a 6-step cycle that starts off with categorizing and mapping information systems, at 1:00 on the diagram. Then it goes to security selection and control implementation. Then risk assessment and security planning. Then determining whether your controls are adequate. Then finally, authorizing or accrediting all of the systems that you have in your environment. If you look at this, it's basically the same cycle that you see in every other standard and regulation.
To close, the whole process of building a compliance programs starts off with assembling your compliance requirements in the context of your business and risk. Next, you need to have good metrics that are documented so that your organization can follow them, both across divisions and over time. Next, you want to build the compliance activities into your everyday operations so that you can create a sustainable process; instead of having it be a project that starts and ends, it's actually activities that all parts of the organization participate in. Then make sure that all those responsibilities and goals are documented well.
A couple of places that people sometimes avoid or miss in this process is that they don't regularly review their goals and their metrics to ensure that they're in concert, or correspond to their current risks, and they don't integrate the compliance activities into everyday operations. Be sure to include that, and you'll be well on your way to establishing a good compliance program.