This chapter covers the initial planning tasks to be worked through before you start with your compliance program. The recipes for this chapter are as follows:
Planning the scope of the basic compliance program
Understanding possible controls for compliance
Evaluating the efforts of controls
Bringing it all together into a basic compliance program
All companies must adhere to regulatory requirements and as such, require a compliance program. For example, when a company trades, it must adhere to its local tax requirements; even a small company must have certain controls in place to ensure it remains compliant. Also, if a company accepts credit card payments, it must have controls in place to ensure it is compliant with the Payment Card Industry Data Security Standard (PCI DSS).
When creating a compliance program, it makes sense to develop processes that will benefit the business. For example, having good controls in place will simplify the audit process, lower insurance premiums, or simply protect against fines.
The purpose of the following recipes is to help you identify and plan a compliance program using System Center in conjunction with other Microsoft technologies. The examples are provided throughout the book, demonstrating how they will benefit your company.
This chapter identifies and defines the first steps in your compliance process based on regulatory standards or similar requirements and how they relate to business objectives. It provides information on how to address compliance requirements with the help of controls. It offers advice on how to interpret authority documents to extract those controls. The book specifically focuses on technical controls.
Scoping is one of the keys to a successful compliance program. Irrespective of company size, you have to decide what to include and what to leave out. When scoping the requirements, take into account all the relevant business, legal, regulatory, and contractual compliance requirements. Requirements will vary from industry to industry and from country to country. Most countries have business accelerators or government agencies providing free advice; make the most of any available service to collect information for your compliance program.
To determine compliance requirements, different information sources can be included to assist program development during the scope-definition phase. The following list provides some potential resources:
Company resources: They can include the company lawyer and internal stakeholders, such as business unit managers from the Human Resources, Finance, Operations, and Information Technology departments; they should know regulatory and contractual compliance requirements for their specific areas.
Internet resources: Generally, they will be specific to each country; the following are some examples:
US: The Sarbanes-Oxley act is mandatory in the US and includes the regulation of financial practice and corporate governance (http://www.soxlaw.com/index.htm).
For small business administration: A dedicated site is available that includes all the government contacts for compliance (http://www.sba.gov/).
UK: Companies Act 2006 (http://www.legislation.gov.uk/ukpga/2006/46/pdfs/ukpga_20060046_en.pdf). More information for UK businesses including information on tax or export compliance can be found on the government website at https://www.gov.uk/.
Australia: The following website may offer a starting point: http://www.standards.org.au/Pages/default.aspx.
Germany: Basic information is offered by the following guide: www.bitkom.org/files/documents/BITKOM_Leitfaden_Compliance.pdf.
In order to define a scope, the following steps have to be taken:
Understand your business compliance requirements and focus on the most critical business processes. Ask yourself the question: What is the primary product or service the business offers? Understand what is relevant to achieve any process or deliver products and/or services, for example, business units, people, applications, systems, data, and devices.
Research the regulatory, contractual, and internal requirements using external resources and internal stakeholders.
Based on the information collected, define your in scope and out of scope objectives.
There are two aspects to scope definition. The first aspect is, "What company assets should you include?" The second aspect is, "Which regulatory requirements or standards to include in your compliance program?"
From a company perspective, the scope definition will include assets, such as physical locations, business units, equipment, application systems, and so on.
For a small or medium-sized company, defining a scope based on the compliance requirements shouldn't be a problem. Most likely, everything has to be included because data of critical applications are directly used in day-to-day business operations. In this case, separating your in scope part of the company and the out of scope part of the company might prove impossible or impractical.
Many smaller companies view compliance as a daunting task and don't start it at all. To avoid this problem, a phased approach is possible. The only consideration for a successful execution of this approach is the ability to define a self-contained scope. The benefit is that results from the first step can be incorporated into the next phase to improve on the compliance process.
For larger or more complex businesses, your decision as to what to include should be based on the following considerations:
In addition, avoid situations where business units, applications, systems, or devices are both in scope and out of scope, because these could lead to breaches in your compliance program. For example, if some users are processing transaction data within an application but have limited privileges, they may be considered out of scope, whereas the IT administrator may have privileges to change data and that needs to be in scope.
That means that physical or logical separation must be possible.
The other question that has to be answered for scope definition is, "What requirements have to be met in order to be compliant?"
Questions that should be asked are as follows:
What are the basic regulatory, standard, or contractual requirements that have to be met? (This will determine which authority documents to focus on as a priority.)
Which regulatory or standard requirements create a high risk for the business in the event of a failure?
The first question is based on the size and legal structure of a business and the industry the company is based in. The following list provides three examples of compliance areas that have to be considered:
Tax compliance: Regardless of the business size, tax compliance starts with creating the business and complies with controls used in most countries that demand registration of your business and regular tax declarations. These controls will include the creation of orders and invoices that show relative tax information and the recording of payments.
Accounting compliance: Just as before, regardless of size, most countries have regulatory or standard requirements demanding integrity or accuracy displayed in an annual financial statement, where the type and content depend on the size and legal structure of your company.
IT compliance: As with contractual requirements, these can be in the form of software license compliance or regulatory requirements, such as data protection.
As an example of IT data protection compliance, let's look at the example from the preface, where we talked about the purchase process and systems holding customer and purchase information. To most companies, the business process that requires this information or data will be critical. Therefore, it should be considered for in scope.
The next question that has to be answered is, "Which regulatory, standard, contractual, or internal requirements must be met?" Data protection laws are one of those basic requirements focusing on protection of the personal data held on individuals. The financial information you hold on your customers, such as their identity information, credit card, or bank information, will fall under this category. Data protection laws vary from country to country; however, they all focus on protecting the data. Ensure that you review the respective laws; information on these laws is generally available and is easy to understand. For example, the authority document of the German protection law Bundesdatenschutzgesetz (BDSG) makes it fairly easy to understand the scope as it states in Appendix to §9 paragraph 1:
Prevent unauthorized access to data processing systems that process or use personalized information (physical access control)
Prevent unauthorized usage of data processing systems (access control)
Based on those two requirements, all locations (or just rooms), applications, networks, and devices that process, transmit, or store that information should be in scope.
The Payment Card Industry Data Security Standard (PCI DSS) is an example of high risk for businesses that accept, process, transmit, or store credit card data. In the event of failure in complying with PCI DSS, credit card companies, such as Visa, American Express, or MasterCard, may revoke the right to process credit card data. This could prove fatal for businesses relying on credit card payments from their customers. For those businesses, PCI DSS will definitely be in scope for fulfillment of an authority document.
Creating a network or architecture map is a great help in order to decide what to include to fulfill the BDSG or PCI DSS requirements. Even if you include everything in your scope, it is important to understand the relationship between your application systems, data flow, and connection points to the outside, meaning everything that is beyond your company network (for example, Internet connections). As shown in the previous example, regulatory requirements focus on specific areas. The data protection laws define certain requirements that have to be met by people (user accounts), applications, systems, and devices that handle the data. You can limit the scope of those requirements to only the relevant systems, devices, or business units.
Using a phased approach, you can start simple and then add details as you move forward with your compliance program. After the initial creation, start adding details of the systems in the network map. An important piece of information is the application used (for example, Exchange), the operating system, and the data flow of your in-scope application systems.
You can use a degree of automation to create a network map. System Center Operations Manager is one of the tools that will help to create such a map. This will ensure that an automated diagram of your network and device landscape is created in an efficient and time-saving manner. In addition, this provides dynamic updating of your network map.
System Center Operations Manager offers different views. The Network Vicinity Dashboard view shows the relationship between network devices and computer (Windows Server) systems. It is a good starting point for a network map.
To view the Network Vicinity Dashboard, perform the following steps:
Open System Center 2012 R2 Operations Manager console.
Select the Monitoring workspace.
Expand the Network Monitoring folder.
Choose the device class you want to see; here, we choose Network Devices.
Go to the Tasks pane and click on Network Vicinity Dashboard.
The dashboard opens. Select Show Computers in the toolbar on top of the dashboard to view network and computer systems.
This recipe identifies controls that may be used to fulfill compliance requirements. In addition, it maps those controls to technologies and tools such as System Center.
Understand your business and the scope for the compliance program based on the Planning the scope of a compliance program recipe.
Controls have two aspects to consider. On one hand, controls will provide you with a handle to fulfill compliance requirements. On the other hand, controls help you define processes and how tasks are done within the company. The most important thing to remember is keeping it simple. Most authority documents demand evidence of compliance but allow you to decide on the actual implementation and use of technology. Wherever possible, use automated controls based on the company's existing technologies.
The type of control implemented as part of the compliance process depends on the acceptance of your auditor, scope, the criticality of the requirement, or (simply) the budget and resources available.
The following illustration provides an overview of the type of controls:
The controls are explained as follows:
Administrative controls: They are most often process-related controls. For example, they influence or shape the activity of a process. Another example is that they reduce inefficiency and/or inconsistency.
Employee-focused controls: They could include training, such as security awareness. The goal is to ensure that the employee knows what he or she is supposed to do and how.
Technical controls: They focus on controls related to technical systems.
General controls: They focus on the overall IT environment. The goal is to ensure that all IT operations are running in a secure and failure-free manner.
Application controls: They are, as the name indicates, focused on the application level. The goal is to ensure that the processing, saving, exporting, and so on of data are correct. For example, technical controls exist to ensure the principles of orderly bookkeeping.
Regardless of compliance requirements, the implementation of administrative and technical controls is essential to ensure the survival of your company. Without any controls, the orderly conduct of business is not possible. In almost any company, some controls exist; however, they might not be obvious, as they are already integrated into the technologies used, or they may exist and not be documented.
There are also different characteristics to controls. Those include the following:
Preventive controls: They try to guard against a risk or an undesired situation from occurring.
Detective controls: They collect data and try to discover inconsistency or whether a risk has occurred based on the collected data. Therefore, the undesired event has taken place, but it will be reported in some way to act upon.
With regard to the fulfillment of compliance requirements, the characteristic of a control must be weighted differently. For example, the most desirable control is an automated, preventive one followed by an automated detective one. Automated controls are viewed as more consistent and are not subject to personal interpretation. Therefore, an auditor will always favor those over manual ones. Keep this in mind when deciding on controls.
The kind of control to use always depends on the situation of the company and the risk the control is supposed to address. Several factors influencing the decision of controls are listed here:
The size of your company
The legal structure of the company
Services or products offered
Employee qualifications
First, let's focus on an administrative control. One requirement might be to ensure the prevention of process inconsistency. The risk might be process inefficiency or an undesired activity by an employee. One example is having the right to enter supplier or customer data including financial data and the right for payment up to a certain limit. In this case, the employee could alter the bank details and then issue a payment; alternatively, the employee could split a payment into two if the bill is higher than his or her allowed payment limit.
The most desired control would be an automated preventive one. In this example, a role-based access control would prevent the first example, as most modern purchase order systems allow the creation of roles and tying those to certain rights or areas. The preventive measure here provides segregation of duty by splitting the process between two employees, preventing risk.
An automated detective control could be to check whether bank information for a certain supplier or customer has been changed right before a payment. To mitigate the second example, check if several payments have been made within a short timeframe with the same reference number.
When focusing on small companies, segregation of duties might not be possible, or the application might not offer role-based access controls. In this case, a manual preventive control could be used. One example is the four-eye principle. In this case, another employee has to approve payment as well.
The least desirable control would be manual detective. The amount of data or the number of transactions due to automated IT systems has been growing so much that inconsistency will most likely not be visible. Nonetheless, a manual detective control could be to pick several payments and check them for orderly processing.
Administrative controls have a protective function, as they try to prevent undesired events from happening. They do not exist to monitor every movement of an employee. Instead, they try to mitigate the risk that an employee might face a situation where, under pressure, an undesirable event could occur.
The next example focuses on technical controls. Again, we will use the purchase order system as an example. As mentioned before, data protection laws require protection of sensitive data. As an example, the German BDSG mentioned in the first recipe requires access control to prevent unauthorized usage. Please refer to Appendix, Useful Websites and Community Resources, for further information on BDSG.
The standard PCI DSS is fairly general, it demands access control in the form of authentication or logon without mentioning any system. As part of an authentication procedure, most companies will use a username and password combination. The kind of authentication procedure might depend on the product or service offered.
For highly sensitive products such as the ones in the military, research, or the medical industry, a more sophisticated implementation might be desirable. This will shape the kind of control required. We will focus on the most common authentication with a username and password. In order to ensure a meaningful password, many companies have an administrative control in place requiring adherence to a password policy.
An automated preventive control is the introduction of Microsoft Active Directory and the creation of a Group Policy Objects (GPO) that demands a certain password complexity. Therefore, a user will be prevented from using shorter, non-compliant passwords. The same thing might be possible within applications.
An automated detective control could be a tool that scans for undesired passwords. In this case, employees could use a non-compliant password, but the administrator would receive a report showing these. The administrator is now in a situation to remediate instances of non-compliance or recommend further action in the case of repeated occurrence.
A manual preventive control could be the usage of password letters. In this case, an employee would create passwords.
A manual detective control isn't feasible to ensure complexity of passwords. However, an example can be ensuring that only relevant people have access to an application. In this case, HR would provide a list of employees who have left the company or changed positions. The compliance team with the IT team would check whether those employees are no longer active in critical applications.
To understand the kind of controls available, you can try using a brainstorm technique. This could include the following:
Talking to application owners to identify existing application controls, for example, roles in an application for an access management control
Researching industry best practices for the objective you have; for example, access (and identity) management offers many papers from Microsoft on how to achieve this using Microsoft Active Directory Domain Service (AD DS)
Researching frameworks that offer a list of controls
The following recipes provide information on how to evaluate controls based on the benefit they have for your business.
Understanding the controls considered and the one-time cost and operational cost associated with them.
When identifying and deciding on the controls, bear in mind the principle keep it simple. Most authority documents only require evidence of compliance but do not demand certain controls. Therefore, use controls that are available within your company whenever possible. When brainstorming for possible controls for a given requirement, use the most efficient and cost-effective one. Many times, one control might not be sufficient, and several controls may have to be implemented to get the desired effect.
The most straightforward approach is to look at the objective and answer the question whether the control will reduce the risk of reaching your objective within an acceptable level. An acceptable level could mean that some controls will not reach their goal. To do this, a matrix is a great help.
A more holistic approach is harder to evaluate, as the cost of a control is most often easier to calculate than the benefit it creates. Still, it should be considered. When deciding on the right control, do not only look at the control itself but at the broader scope the control has on your business. It is important to understand what technology could be used to implement this control or what technology is underlying the control and could be used to create benefits to the business. The following illustration provides some examples on cost versus benefit for controls that help evaluate which controls to choose:
Automated controls are always more desirable than manual ones. The cost effectiveness of such controls comes from the following:
Automation of monitoring and regulation activities
Achievement of a much higher coverage through automated controls, for example, an example eliminating a higher percentage of (fraud) risks
Creating process efficiency
Creation of objective controls as they lower audit costs
In the previous recipes, we talked about compliance requirements for access and authentication management. In the next recipe, we will discuss authorization.
Access and identity management is a compliance requirement that is found in different regulatory requirements. In cases where identity lifecycle management is purely a manual activity, creating controls for this might may seem like creating more manual work; however, by introducing Microsoft Active Directory Domain Services, the identity lifecycle management process, including deletion and changes, will be more efficient.
GPO for password compliance is an automated control already within the AD DS. The only manual effort is deciding on GPO and configuring it within AD DS. The overall one-time cost of planning an Active Directory Domain and implementing it will outweigh the cost and resources required for manual activities, such as using creation and management in each and every application as well as ensuring password compliance to meet requirements. Hence, the potential exists to create more efficient processes within systems and applications.
Audit costs are quite often lower for automated controls than for manual ones. Automated controls do not face the risk of human error or subjective interpretation. Therefore, auditors require more evidence that a manual control is effective, thus qualifying for the goal of the control.
Another qualifier for an automated control is a detective one, as those could help to minimize undesirable cash outflow. Think about an example; suppose that the wrong supplier has been chosen, leading to the loss of favorable supplier conditions, such as discounts.
The competitive advantage should be considered to evaluate the usage of a control. Controls help prevent failure of the company or a certain unit. As an example, take PCI DSS and the result of noncompliance.
Creating a compliance program could open up new markets, while noncompliance could eliminate them. The PCI DSS mentioned in the previous recipe is an example of eliminating a customer base in the case of noncompliance. As mentioned before, without compliance, the credit institutes reserve the right to revoke processing of credit cards.
Another competitive benefit of compliance controls is opening up new customers and markets. One of the most basic compliance regulations, tax compliance, is such an example. In many countries, governmental bidding invitations are only open to companies that have declared tax in time and have paid their taxes. The consequence of noncompliance could be the loss of potential orders.
More companies demand certain IT security certification to be eligible to provide a bid. As IT security is one of the aspects of many regulatory requirements, the first step toward such a certificate is already made.
This recipe provides advice and examples on how to read an authority document and extract the requirements it contains. In addition, the recipe will provide examples on how to translate those requirements into controls.
Obtain the authority documents that you want to focus on. Most of them are available on the Internet.
Work through the previous recipes Planning the scope of a compliance program and Understanding possible controls for compliance.
The key is to understand the authority documents. The first step is to extract the required control objectives or the goal(s) and, based on the required evidence or activities, to define the control activities. After identifying and defining the control objectives and control activities, the next step is to relate those to the actual implementation within the business. The process looks as shown in the following illustration:
Understanding the terms of the authority document is essential as each authority document might put a different meaning on key terms. Sometimes, the authority documents contain explanations of such key terms. Quite often, there are accompanying documents that offer more detailed explanations.
For example, the German BDSG defines key terms in §1 to §3. In addition, the Federal Commissioner for Data Protection and Freedom of Information (FfDF) provides the document BDSG – Text and Explanations that comments not only on key terms but also on objectives and required controls.
The next step in creating your compliance program is to identify objectives and/or requirements based on keywords within the authority document. Examples of such keywords are control, monitor, prevent, protect, identify, and so on. Note those paragraphs as they are the input for the next step. In addition, if authority documents are updated or changed, you know the origin of a certain control objective or control activity. Knowing the originals will make it much easier to incorporate updates or changes into your compliance program.
For example, the German BDSG is quite clear on objectives. As mentioned before, Appendix (to §9 paragraph 1) states the following:
3. to ensure that people authorized to use a data processing system can only access data they are authorized for, …(access control),
This example is easy to understand as the keyword, access control, already states the control objective or goal. Ensuring access management is the control objective we have to look at.
The next step in our process is to identify controls that fulfill this objective. In order to do this, the following two questions should be answered:
What is necessary for a risk not to occur?
What reasonable steps and control(s) do we have to implement to reach the goal?
Going back to the example from step 2, the risk addressed is unauthorized access. Therefore, the authority documents focus on the authorization mechanism. The controls have to ensure the risk is limited and/or mitigated.
Implement the correct scope that is relevant to the effort required to implement each control.
Based on the authority document, we know that sensitive personal data is included; thus, with regard to our purchase order system, all sensitive data within it will be in scope. We also know, based on the previous example, that any person with access to this information within the application must be included. The focus here is on the digital person, meaning their technical identity, such as user accounts.
Depending on your company and environment, different controls could be used. Thinking back on the type of control, an application control such as automated preventive is most desirable. A sophisticated approach is to use a role-based access control. This requires an application system that provides capabilities to create roles with rights to access certain information or functions and to actually configure and use those capabilities. In this case, the application itself will automatically prevent users from accessing information they are not authorized for. Looking at our example of a purchase order system, most applications already provide such functions and role concepts. They just have to be configured. The benefit of using such a control is quite high, while the cost incurred is quite low.
Some applications do not offer such role-based access controls. In this case, a manual preventive control could be used to ensure basic authorization control. A possible control is an approval process. Before a system administrator grants access to the application, the line manager and information owner have to authorize access to the application and data for that given user. The prerequisite is that an authorization mechanism is configured for the application.
The last step is to understand those controls in the broader scope—that of the business. BDSG will not be the only authority document requesting controls in access management. Look at the broader scope and evaluate whether a more generalized approach is more appropriate. Creating either the automated or manual control will benefit the company, as it will minimize the risk of fraud. The authority document states that people authorized to use the application are in scope as well as the application.
While evaluating the controls, the implementation of role-based access control or access management controls might be more expensive and time-consuming at the first view. However, considering that most likely not only one application but many applications have to have access management (authorization) controls, it might be more cost-effective to consider the broader scope using a role-based access management solution. To manage those access rights consistently and efficiently, they should not be configured individually. Instead, access rights should be given on a group level, most likely standing for a certain role those people have. Each role or group allows the fulfillment of a certain aspect of a job, such as managing purchase orders or approving purchase orders. So, all rights required to manage purchase orders, such as creating, changing, or deleting orders, will be included. The usage of those roles will have the added benefit of making the access and identity management process much more efficient for administrators.
The following table provides further examples on control objectives and possible technical implementations for controls with regard to the authority document:
|
Authority document |
Authority document goal |
Technology to achieve goal |
Scope |
Cost/benefit |
|---|---|---|---|---|
|
PCI DSS – 7.1 Limits access to system components and cardholder data to only those individuals whose job requires such access |
Ensures access management |
Segregation of duty within the application and OS Use of automation, such as System Center Orchestrator (SCO), to grant access based on roles |
All accounts/applications with access to cardholder data |
Cost: Planning and implementation of segregation of duty Benefit: Process enhancement, for example, automated provision of accounts Reduces risk of fraud |
|
Sarbenes Oxley Act (SOX) – Section 404 Demands annual report on adequate internal control for financial reporting |
Several goals, for example, monitoring |
Audit trails or logs of applications use SCOM ACS for monitoring |
All critical applications with financial transactions (criticality must be defined by business) |
Cost: Planning and implementation of SCOM ACS Benefit: Reputation |
Many authority documents will not provide clear and detailed information on the goals and how to realize them. The preceding categories should guide you in how to take them apart to determine control objectives, subsequently control activities, and determine what Microsoft technologies to use to achieve them.
The compliance program you create and manage will help to ensure adherence to compliance requirements. The results of the compliance program are only as good as your understanding of the authority document and implemented controls. A thorough planning phase is very important.
Adopt the steps described previously according to your specific requirements and company.
Prioritize your authority document and control implementation. For example, you could create a matrix for high risks, putting in all regulations or standards that have a high impact on your business. As shown in previous recipes, if you depend on credit card payments from customers, fulfillment of the PCI DSS standard is essential to your continuous business operations. So this should receive high risk.
Export compliance is essential to any international freight shipping business; otherwise, it might be considered low priority. It has to be considered but not in the first phase.
Likewise, consider controls that are easy to implement and cover a large number of requirements. There are many more examples, so look at the authority documents, and understand how they impact your business and which controls will fulfill those requirements.