Compliance Requires Layered Security
Businesses need to worry about more than just developing products and services for their customers. They need to deliver those products and services while complying with a plethora of standards and regulations governing how data can be collected, processed, stored and transferred. These standards range from highly specific documents covering niche markets like healthcare, to customer-defined specifications such as those of the U.S. Department of Defense (DoD), to user-based requirements like General Data Protection Regulation (GDPR).
Regulations are nominally crafted to protect user privacy and prevent data breaches. Comply with the regulations, the thinking goes, and the system will be secure. Unfortunately, that isn’t necessarily the case. A system and application can be compliant without being secure or, occasionally, secure without being compliant. Success begins with gaining a thorough understanding of security best practices, what constitutes compliance with the standard and how to develop a structure that addresses both needs while maintaining business value.
Compliance Isn’t Security
Regulations and standards governing digital operations are generally developed with the intention of increasing protection for the customer. In some cases, such as the Health Insurance Portability and Accountability Act (HIPAA) and GDPR, the regulation is established and enforced by government agencies. In others, such as the Payment Card Industry Data Security Standard (PCI DSS), development and enforcement of the standard fall to industry organizations and the companies involved. In either case, penalties for noncompliance can be substantial. Businesses focus on compliance because meeting the relevant standards is essential.
Particularly in the digital domain, compliance may be a necessary condition for doing business, but is far from sufficient. Perhaps the biggest misconception around digital regulatory frameworks is that regulatory compliancy equates to security. That’s not necessarily true. “You should always focus on security before compliancy because you can achieve compliancy through security,” says Westley McDuffie, security evangelist, IBM. “You can’t necessarily achieve security through compliance.”
As an example, the HIPAA Security Rule is designed to provide guidelines for protecting electronic health information. Because the rule was built to address a range of enterprises and circumstances, it’s also general. For example, the rule mandates that every user have a unique username and password. That requirement in and of itself isn’t sufficient enough to protect against data breaches.
“The HIPAA Security Rule doesn’t state what kind of password to use, it just calls for a password,” says McDuffie. “If you use a simple password, the system isn’t secure but your organization is compliant. If I change it to a strong password, that’s still really not secure because I can break a password. If I go to two-factor authentication with a smart card or an RSA token, now I’ve increased my security posture. I’m doing something that’s more secure and I still meet the compliancy guideline.”
Conversely, a highly secure system may not be compliant. Suppliers to the DoD must work with components that meet specific Security Technical Implementation Guides (STIGs) mandates. A device might offer a higher degree of security than DoD-certified counterparts, but an enterprise can’t use it on their project because it hasn’t been validated—it will be secure but not compliant. The goal is to have a system that is both secure and compliant.
“Do a deep dive into what you actually have before you make any other changes to your policies, to your networks, to your people.”
—Westley McDuffie, security evangelist, IBM
Getting Started
Satisfying the rules of a regulation starts with a thorough understanding of what compliance means. Someone in the organization must take ownership of this task and drill down into the details. The ownership process involves learning not just the rules but the intent of the standard. “It requires more than a quick one-hour class,” says McDuffie. “Someone needs to delve into the standard in depth to truly understand what constitutes compliance and how this can be implemented in a more security-focused way.”
Developing a secure and compliant network begins with a thorough audit of the system. “Do a deep dive into what you actually have before you make any other changes to your policies, to your networks, to your people,” he says. “You need to see what you’ve got to work with because chances are, you don’t know. If your team can’t describe your basic infrastructure to 100 percent, you can’t have a clear understanding of the security and compliance of your network because you’re missing the foundation.”
First, inventory assets on your network, including the number of licenses and OSes, the location of access points, routers and switches, and so on. Next, perform a vulnerability assessment. Review passwords, check to see whether software is up to date. Run a network scan for vulnerabilities. The intent of the process is to uncover issues that need to be corrected to result in a secure and compliant system.
The process is detailed and time-consuming. Depending on an organization’s IT resources, the best approach may be to use an outside firm. “Some egos are going to get bruised but that isn’t the point of what’s happening,” says McDuffie. “You conduct the network assessment, the vulnerability assessment, the asset assessment, the policy assessment to see what is and what isn’t updated, and where the problems lie. A good assessment team will not only assist in this endeavor, they will help you build a solid foundation on which to establish your security mantra.”
Security Best Practices
Once vulnerabilities have been identified, the next step is to develop a strategy to secure the network and bring it into compliance with the appropriate standards or regulations. Four verticals in every organization need representation: people, data, infrastructure and applications. Placing security controls around these four areas should be the basis of the security practice.
Organizations have multiple options for remediating potential issues. They can either focus on the most critical vulnerabilities first or rank them by expense (i.e., no cost, low cost and higher cost). “I like a combination of the two that mixes the power of no with the power of know,” says McDuffie.
Security measures should follow best practices using a layered security approach. Strong passwords and two-factor authentication are important first steps. Implementing role-based access further reduces the number of attack vectors. The approach can be enhanced with layered encryption that not only encodes data in motion but also data at rest to minimize vulnerabilities. Hacking the password of a system administrator won’t allow an attacker to take advantage of customer data if the system administrator is blocked from seeing raw data.
DoD STIG provides another example of an approach to restricting attack vectors. DoD STIG requires the removal of any unnecessary programs and port numbers from hardware before it can be certified as compliant. The idea is to leave the bare minimum of hardware and software assets required for the work.
Taking steps to create a secure and compliant system is the most difficult part of the process and it requires the most expertise. Software tools are available that can scan code to isolate vulnerabilities and recommend changes to ensure compliance. Alternatively, the same companies that perform security audits and network analysis can typically assist with these steps.
The security measures should go beyond the current implementation. The process should involve a policy audit and a policy update to reflect best practices. Security should be included by design. Software development should follow a DevSecOps approach, for example, so that software architects and programmers build security into applications from the very beginning.
“You’ll drive yourself crazy trying to find the perfect solution. It doesn’t exist. Everything is a risk and you must accept that. Remember, security shouldn’t affect the day-to-day operations of the company.”
—Westley McDuffie
Risk Management
The only truly secure computing platform is one that is encased in concrete and buried underground. In our connected world, security is an exercise in risk mitigation. Organizations need to achieve compliance and the best security profile possible while also supporting the business mission of the organization. “You’ll drive yourself crazy trying to find the perfect solution,” says McDuffie. “It doesn’t exist. Everything is a risk and you must accept that. Remember, security shouldn’t affect the day-to-day operations of the company.”
Ultimately, security is a balancing act. Risk avoidance is important but if taken too far, security interferes with the ability of the user to do the work. At this point, the process must transition to one of risk acceptance. Organizations need to determine what they’re willing to pay for security, both in terms of processing latency and budget. In the former case, overly stringent security measures can potentially drive customers away. In the latter case, budgets are always limited and companies seek the best overall protection at the lowest possible price.
An example might be a chipset with a known vulnerability but one that requires significant expertise to exploit. Mitigating the issue would be expensive, consuming resources that could be used to address a number of other lower-level but more commonly used attack vectors. It becomes a question of risk management. “The goal is to plug as many security holes as possible with the fewest resources possible,” says McDuffie. “Companies should review the residual risk and determine whether they’re willing to accept it. If they’re not, they go through the process again until they achieve a satisfactory outcome.”
When a security mechanism can achieve compliancy, that’s the route you want to go whenever possible. When a security mechanism enables you to execute multiple facets of your security policy in your doctrine compared to just compliancy, that’s the approach you want to take, assuming it meets your compliancy needs.