Bringing it all together into a basic compliance program
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.
Getting ready
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.
How to do it...
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:
Step 1 – understanding the terms of the authority document
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.
Step 2 – identifying objects and/or requirements based on key words
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.
Step 3 – identifying controls that fulfill this objective
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.
Step 4 – mapping controls to your business – defining the scope
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.
Step 5 – mapping controls to your business – defining the type of controls
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.
Step 6 – mapping controls to your business – defining the broader scope to simplify controls
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.
How it works...
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.
