Compliance May Not Be Sexy, But It Is Necessary

Compliance (as a practice) has grown in importance alongside the development and adoption of computing in business. This is a natural result, since as the volume of business activities increased, so did the risks, threats, and consequential losses. 

The rise of compliance programs really took off in the early 2000s in part due to large organizations’ and governmental agencies’ awareness of the risks involved to businesses and their operations. The resulting compliance programs (such as PCI, HIPAA, and FISMA) aim to encourage security in both design and operations of computing. Compliance authorities, such as the US Government (FISMA, HIPAA) and the consortium of Credit Card lenders (PCI), design and enforce compliance programs. They know what risks are greatest in the community they focus on, and so they emphasize continual improvement of those systems and practices (controls) that mitigate threats and remediate vulnerabilities.  

In achieving compliance at your organization, you need to understand that compliance is a starting point towards meeting security and operational best practices. And although compliance controls are not a guarantee of security, failure to comply can result in potential fees, loss of business, and loss of customer trust. Additionally, compliance is not a once-and-forget-it activity. Many programs typically audit annually for evidence of year-round compliance, and programs regularly update their focus and requirements to meet perceived threats and risk areas. 

So, you cannot simply ignore compliance; yet, it can be a challenge to achieve the right frame of mind to maintain it.

The Challenges 

There are a number of challenges when it comes to compliance programs. Here below, we give some details. 

They’re More of an Intrusion, Not a Help

First, there is the fact that a compliance authority (an outside entity) is dictating requirements for your operations and security teams. Like many individuals, your organization may resent the oversight and instructional tone of many compliance requirements. Many organizations are so busy building and maintaining a business, that the compliance requirements appear to be adding tasks and not helping at all. 

Comprehension Barrier

Also, many people often read compliance sources and feel they are actually difficult to interpret. For instance, the HIPAA security rules are sourced from US federal laws, which are challenging to understand for people not in the fields of law and compliance. The language of the text rarely directly states “you will do x,” but describes the outcome and intent. For most people in IT and security fields, this can be very difficult to interpret. And to make matters worse, many compliance rules and requirements are often based on an interpretation of “risk,” meaning that the requirement is meant to be scoped and adjusted from an analysis of the level of risk specific to your organization. This organizational risk score is often hard to come by. 

Converting a concept into effective tasks can be a challenge to your compliance team if they do not have the experience or skills to assess threats and vulnerabilities, do not understand the nature of the technology and architecture of your data processing environment, nor have the ability to perform risk assessment, recommend risk mitigation and remediation, and improve the maturity of IT and systems operations. 

To comprehend the compliance field requires some planning and sometimes collaboration with legal, security, engineering and others in your industry to ensure your approach to compliance is in line with legal requirements and an auditor’s understanding.    

All Aboard!

Aside from the challenge of correctly identifying and applying technical compliance controls within your organization, there are the additional challenges of getting everyone on board with the process. Without management and staff support, you are certain to have pushback by operations staff, who may not understand the connection between compliance and security operations or the risk to the company at all. Phrases such as “tone from the top,” and a “culture of security,” are often used to describe a firm that has success with compliance. 

Without the support and understanding of operations, the challenge of applying compliance controls is likely to fail over time or create expensive and unnecessary costs to the organization.

The Value: Improved/Matured Security & Operations

Perhaps the top value of compliance programs is that they can provide valuable guardrails to operations. This means that they can provide a minimum baseline for security actions that are owned and controlled by your organization and support processes that allow your firm to grow in a secure manner. It’s important to consider that operations should be moving forward towards maturity in a progressive manner (e.g., CMMI) and that compliance requirements are actually common-sense requirements addressed during the process of maturing.

Use Case: Payment Cards

When you examine a compliance program’s requirements, for instance, for the Payment Card Industry (PCI), the requirements are designed to apply a framework of controls to operations with the goal of protecting a specific sensitive type of data (cardholder and cardholder transactions). You cannot fault the focus, since this type of data is clearly at risk and abuse of this type of data can result in real losses to the banks, cardholders, and merchants. 

With this common point of view, the mechanics of the requirements make more sense. For instance, looking at the PCI DSS Requirement 6: “Develop and maintain secure systems and applications… All critical systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.” This is stating a practical and clear way to protect against vulnerabilities in systems and software. The value of the PCI framework provides a process (ref: PCI DSS Requirement 6.2) that guides operations to prioritize critical system patches and deploy them to operations based on the criticality of those systems to the business. 

Best Practices to Enhance Value

Operations and security personnel typically agree that when compliance requirements “make sense,” then it is easier to support and maintain those requirements. When an organization takes time to explain and highlight its compliance position, it often finds operations are already partially compliant; it is also easier to task informed staff. 

Facilitate Comprehension

The challenge to meeting compliance efforts (such as PCI) may be that the application of mitigating controls and the documentation of those controls may be lacking. When you consider that meeting compliance requirements is often about documenting and normalizing existing best practices, there is less pushback by staff if you make operations procedures more consistent and better understood by all involved. This may help reduce concern that the compliance effort is overwhelming, improve the maturity of the solution, and enhance support for the program.

Prioritize

Another best practice for a compliance rollout is to prioritize those technical controls that will be foundational to the security operations going forward. Typically, these are controls that address both mechanics and procedures. Think of the Security Development Life Cycle (SDLC), which mandates security considerations throughout the development of systems and software, not just adding it (bolting it on) to the end product. The SDLC process becomes the framework that assures security considerations/requirements are built into and tested prior to the release of a product.  

Patch Management

You should also consider Patch Management–discussed further below–as part of your normal system security management. This should include alerting, assessing, testing, and performing a controlled rollout of patches and fixes as part of a business’s vulnerability management and change control process.

When control operations are compliant, they add stability to the operations team, who can then rely on a well-known and practiced operation instead of considering the compliance requirements as an afterthought. Furthermore, by removing resentment of the required practices, the company compliance effort is less stressed by compliance audits.

Patch Management Solution

When you examine multiple compliance programs, you find many programs are essentially focused on a core set of security operations and efforts. One of these core precepts is vulnerability management due to the risk of system failure, hacking, or loss that result from running systems with known vulnerabilities or weaknesses. Because unpatched systems have been identified as one of the top causes of data breaches for businesses, there is a focus on patch management as a compliance solution.

Your business, like many others, is likely to run a combination of operating systems, applications, and systems from a variety of vendors and for a range operations. Your operations team already knows they need to identify those vendors that can send you patches or notifications of patches. However, they may not have worked out a process to:

• Understand all the vendors they have to contact to address the entire inventory of systems and the patch impact (risk and functionality) on your systems, including if you can afford to automatically deploy patches or if they have to be tested and approved before proceeding.
• Examine all tertiary systems (e.g., e-commerce sites, SaaS vendors, backend systems) that may also need defending from vulnerabilities.  

Without full knowledge of what systems you deploy and what patch management approach is needed with each one, your team may struggle to achieve initial compliance as well as maintain it over time.

Careful Consideration of the Vulnerability Remediation Process

Since we are not going to fix the multi-vendor complexity any time soon, it pays to develop and consider the patch management process as part of your core maturity in operations. By creating a compliant process for patch remediation, your compliance program will have a control procedure for identifying the patch management approach from inception (selecting a product and vendor) to the steps required to address alerts, risk analysis, testing, and, finally, approval for deployment processes. This way, you can ensure your systems are protected and supported as quickly as possible.  

A mature patch management process within a complex multi-vendor environment is likely to be helped by the automation of tasks that can be easily missed on manual processes, including the prioritization of systems based on risk assessment, testing of updates, and deployment. Automation can minimize human errors and increase the patch optimization process, resulting in less downtime. Also, automation will help with reporting on successful deployments (a compliance requirement) as well as with automated rollbacks and alerting on failed efforts. 

Conclusion

Approaching compliance is a challenge for many organizations. However, understanding it as part of maturing operations helps to lessen the pushback and integrate good, sensible operating principles that will serve the organization over the long haul. 

Our example of patch management as a compliance requirement (such as in PCI) underscores that this requirement actually supports risk assessment, vendor management, vulnerability, and change control processes. The activities of patch management directly address threats, such as data breach and loss of data, which can be far more expensive than the effort required to become, and stay, compliant.