The Compliance and Audit Lifecycle of a People-First Security Program
When Processes Change, Policies ChangeAs you adopted cloud technologies like Software-as-a-Service (SaaS) applications, you needed to find ways to secure the remote identities. This change in process, changed how you managed your people. To secure access, you brought in a new technology – multi-factor authorization. This protected your SaaS applications from unauthorized users, or at least tried to. Today, people are not the only ones that need passwords for access to systems and networks. Devices, applications, printers, service accounts, and automated robotic process automations all utilize passwords and, as with people, need multi-factor authentication to secure their access to and within your cloud infrastructures. This example highlights the thought process needed to write and implement effective policies. If policy writers think one step ahead, focus on the whole process not just react to a new event, the policies better match your organization’s needs.
When The Prescriptive Models Create Audit FailuresMany of the first compliance models were based on prescriptive technologies. These industry standards and regulations, such as PCI DSS, HIPAA, ISO, or NIST, date back to the late 1990’s or early 2000’s, when most companies delivered IT through their on-premises architectures. The policies written to meet audit requirements were created with the auditor in mind. The IT auditors, hopefully more tech-savvy than the average employee, understood the terminologies, processes, and goals. However, the people affected by the policies often lacked context. This confusion led to countless meetings with stakeholders ranging from the c-suite to the standard employee to discuss what the policy means, who it applies to, and how implementing an enabling technology reduced risks involved. Many people affected by the change walk out of the meetings, shaking their heads, and saying, “I’ll just keep working as I have been and produce the same looking report when audit asks for it.” Unfortunately, these prescriptive models take a long time to update. Creating policies and procedures based solely on their requirements does not protect the organization. In fact, your compliance with one prescriptive technology requirement may not meet another, risk-based or outcome based audit requirement.
How to Base Your Policy on PeopleIn some cases, the policy writer remains disconnected from the operational technology in use. In other cases, the audit staff only knows that at one point the company used a specific technology. The IT, compliance, and audit functions all operated independently from one another. However, if you update your mindset to focus on a People-based policy, including thinking of your different internal departments as people-based not faceless monoliths, you can make your policies more effective and less prescriptive. The baseline purpose of your policy is to effectively manage your solutions: tracking who accessed what resources, who managed those resources, who can provide detailed information about access, and who can detail the business impact if things go awry. Instead of thinking of compliance as a “task,” start thinking about it as a People-driven process. To create a People-based security model, you can use Identity to help focus on three key components: purpose, key performance indicators, and auditable outcomes.
How to Define A Clear PurposeWhen you create a People-focused strategy, you start with the people and their behaviors, not the compliance standard or regulation. While that may seem counter-intuitive, the compliance requirements began because companies were not protecting people’s data. Their primary purpose is to require privacy and security. If you start from their purpose, you can define your own. Ask yourself the following questions: Ques- That behaviour do we want to encourage with this policy? Ans- Your policy is to protect your customers information, not to produce a report for an auditor. Ques- Who are my stakeholders? Ans- Identify the people that need to be involved, and realize that the scope of individuals involved is larger than you might realize. Keep focused on the business outcome. Ques- What standards and regulations do I need to comply with? Ans- If you need to be PCI-DSS compliant say so. If you need to be HIPAA compliant as well, make sure you include that. This can help focus your audit scope. Ques- Who is responsible for the day-to-day management and enforcement of the policy? Ans- Define the people responsible for managing the affected business solution. For example, if you need to be PIC DSS compliant, you need to assign access rights to the right systems and solutions, document the access requirements, and assign someone to enforce the access rights in the policy The people with access to the data matter more to protecting the information than then people setting up the system; however but both sets of people play a role in delivering a safe solution Can I explain this to everyone who needs to understand it? Enforcing a policy is easier when you communicate its importance to everyone in language they understand. For example, a policy for “Cisco VPN” usage is technically correct, but many people may recognize it more easily as the “Gold Lock Thing.” Communicating the policy to users and auditors may need different language. Less technical jargon can go a long way.
How to Make it MeasurablePolicies set the rules, but you also need to make sure that you measure how well people are following the rules. To do this, you need to create key performance indicators. Some questions to ask include:
- Are there specific measurements that can be attributed to each policy?
- Can you get a count from an automated system that tells you when there are policy violations?
- Can you get the number of times that policy actually gets utilized properly?
- How many policy exceptions are there?
- How are we monitoring these exceptions to keep them current or to remove them?
How to Produce Audit DocumentationThe final step to creating a People-focused security program lies in documenting the entire process for your auditor. This documentation includes the risk assessment, policy, and your reports proving that the controls were effective. When trying to pull together your audit documentation, you want to include:
- Logs showing all user activity, including your privileged users
- Any minutes from meetings where you reviewed security events
- Exceptions to the policy
- Duration that the exception lasted
- Proof that you reviewed all documentation to ensure policy enforcement