In performing SOC audits for Linford & CO, the clear majority of organizations do a great job providing reasonable assurance they are meeting all their controls. But I wanted to hit on a list of seven common mistakes that seem to pop up to hopefully help your organization identify them before they become an issue. All the common mistakes below may qualify a report, create exceptions and/or create a less secure environment, leaving your organization susceptible to external attacks. The list is not exhaustive, it is just a sample of common mistakes and recommendations. Each environment is different and what works for one organization may not work for others.
No or Lack of Organizational Buy-In
Lack of buy-in is an issue for every organization and is not specific to those undergoing a SOC 1 and/or SOC 2 audit. Many times, it can just be a nuisance that may impact performance, but when it comes to security compliance, it can be particularly bad. If an organization does not follow the defined policies and processes, it can lead to a less secure system, qualified report or even a breach. A single person not following the process could cause major damage. For example, if employees are not allowed to download software from the internet but one rogue admin downloads malware and installs it on a server, the organization’s security could be compromised.
Educating staff about the purpose and benefits of policies and getting their commitment to comply are essential for obtaining and maintaining compliance.
Inaccurate Access Controls and Permissions
Access control is an important topic and there are books written on how to implement. In this instance, I want to focus on off-boarding and making sure to remove a user’s access when it is no longer needed. When a staff member changes their job function or leaves the company, it is essential to ensure that their access to the system is reviewed and updated accordingly, otherwise they may end up retaining privileged access when they should not. This sounds like a simple task, but when you add in that an organization may have many different applications, disconnected systems, last second changes, high priority issues, etc. a mistake is bound to happen.
There are many ways to avoid this mistake, and below are just a few of them. Simply being aware of this gets you much closer to defining a way to protect against it.
- Document which products have access controls and the roles/permissions that are defined in each. When a user changes positions or leaves the company, having a detailed and accurate list will help ensure that their permissions are updated/removed appropriately.
- Review roles and permissions on a regular basis. This will help one identify if a user was not removed or a permission change was missed.
- Document changes to a user’s permissions in a service ticket or checklist and retain this information. This provides historical evidence of the actions taken.
Poor or Nonexistent Inventory Management
Accurate inventory management is fundamental to maintaining a secure system and being able to successfully obtain and maintain compliance. If an organization does not know what is on their network, how are they supposed to ensure everything is patched and monitored? Rogue machines happen all the time, most frequently because lifecycle management breaks down and a machine that is supposed to be decommissioned continues to chug along, or with Bring Your Own Device (BYOD), devices are coming on and off the network all the time. A single rogue device can be the downfall of even the most secure system.
Maintaining an accurate inventory of assets requires both technical and manual processes and procedures, but the key to success is being diligent and monitoring frequently. Find a process and product/tool that works for your organization. An organization can spend millions implementing a commercial product, but if they never maintain it, all that money and time is for nothing.
Knowing what you have is only one part of inventory management, identifying what is not known or not approved is where it can get tricky. To help find these unknown devices, organizations can do periodic sweeps of the network, pull information from network devices, implement Mobile Device Manager (MDM) products, log wireless devices, etc.
Unknown External Communications
Knowing and understanding the organization’s external communications is key to securing the system and obtaining and maintaining compliance. External communications interface with vendors, third-party tools, etc. and are usually the primary methods of contact with the organization’s customer base. Having insecure or unknown external communications greatly increases an organization’s chance of a breach.
In 2015, the POODLE attack made SSLv3 obsolete and insecure. It is recommended organization’s disable this protocol, but according to the 2016 TLS Telemetry Report provided by F5 Labs, as of October 2016, 23% of the internet at large still is supporting it. Without an external vulnerability scan or well documented and reviewed interface documents, organizations may still be using an insecure protocol and not even know it.
Performing external vulnerability scans and/or penetration tests is a great way to determine the security of your external connections and network configuration. I also like to recommend that every organization document their connections and review the connection details periodically.
Note: I recommend contacting your vendors for details on how to disable SSLv3. http://disablessl3.com/ is also a good resource to help your organization identify and disable the protocol.
No Separation of Duties
Separation of duty means that in order to complete a task, more than one person is required. When talking about systems, this is especially important when it comes to Change Management. In Change Management, you do not want to allow the same person to build, test and push updates to production. If only one person can do everything, it creates an environment where a coding mistake could be pushed into production, or more nefarious acts like installing a backdoor into the system, can be done without anyone knowing.
In larger organizations, separation of duties is overcome by adding more resources, but it becomes a bit more difficult in a smaller organization where there are few resources with the skill set to know if the code is written correctly, which may introduce a security risk to the system. The key to implementing separation of duties is to ensure the resources are knowledgeable with regards to their job function and that changes to the system require at least two people to implement. Also, removing developer access to push updates into production and forcing a review will limit the risks with regard to Change Management.
Not Monitoring Subservice Organizations
In a previous post, Newel Linford stated: “Subservice organizations perform at least some function of the service organizations’ outsourcing activities. If the subservices perform functions that are relevant to the user organizations, then the user organization needs to verify that the subservice is fulfilling their obligations.” Many times, the user organizations don’t review if the subservice organization is meeting their controls, which may lead to a control not being covered at all.
A user organization should be reviewing and monitoring their subservice organizations to ensure that they are fulfilling their obligations as well as understanding what role the user organization should be fulfilling.
Poor Scoping of the Report
One of the first steps of obtaining a SOC report is to define the scope. If an organization specializes in a certain service it can be simple and straightforward, but what if the organization offers many different services? If an organization does not properly cover all the risks related to the services provided, they could end up being deficient in certain areas, or on the flip side, it may end up costing the company quite a bit of time and resources to enhance or add controls that are not required.
Understanding the service’s scope and boundaries starts with understanding the people, processes and technology that support the service. From there, determine which risks are related to the service(s) provided, generally through a risk matrix, and ensure that each risk is being addressed. If an organization has not been directly told which type of report is required by their customer or auditor, then the organization would also need to identify which report type is necessary. SOC 1 reports are for internal controls over financial reporting, and a SOC 2 report includes security, confidentiality, processing integrity, availability and privacy. For additional information on what report you may need, see: Need A SOC Report? How To Know Which One Is Best For Your Service Organization.
Whether you are preparing for your first SOC audit or have been through an audit before, the above common mistakes can sneak up on any organization and each one could qualify a report, create exceptions, and/or create a less secure environment. Stay diligent, know your environment and monitor changes. With proper processes and team buy-in, your SOC audit can be smooth and free of issues.