Compliance Requires Layered Security
Success begins by understanding security best practices, what constitutes compliance with the standard and how to develop a structure that addresses both needs.
By Kristin Lewotsky03/01/2019
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
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
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.
Compliance Alone Isn't Enough
For many companies, regulatory compliance is a necessary condition for being in business. However, it’s important to remember that compliance alone isn’t sufficient. Organizations should start by carefully reviewing the standards to both understand what compliance entails and also identify the gaps left between compliance and secure operations. Next, a thorough security review enables companies to determine where they satisfy regulations and security best practices, where they fall short, and what is required to satisfy both sets of conditions. Codifying the approach in the corporate security policy helps ensure going forward.
Sponsored Content: Achieve Compliance Without Impacting Productivity
Implementation of proper audit trails and authorizations for mainframe systems maintenance can be a daunting task. The need to react quickly to maintain a secure, continuously available computing environment collides with the workload of satisfying compliance and audit requirements for changes, making an already complex task even more so. Adding multiple steps or changing the way systems programmers currently work can impede their ability to make prompt changes.
Systems programmers must use a wide variety of tools to perform their jobs. A single change management process for everyone is not possible in today’s environment. Solving this dilemma requires an automated way of generating audit trails and obtaining authorizations without adding manual steps or changing the way systems programmers currently work. Such a solution should fit in transparently with current tools and be easy to implement, while adding value to these existing processes.
In addition, this solution should provide a means to leverage its audit trails to provide further functionality. For example, propagating real-time event information to SIEM systems enhances the analysis of alerts for security monitoring and protecting your data from threats, and satisfying increasing governance and compliance requirements.
Vice president, Action Software International
Peter has over 30 years of systems change management experience working with the world’s largest institutions.
Sponsored Content: 6 Ways for IT to Overcome the Business Disconnect
Analytics with automation is one of several ways that mainframe IT management can overcome the disconnect with the business. Rather than being perceived as a dated organization lacking agility, IT can get a seat at the table with the rest of the management team to move the company forward. The following are suggestions for keeping your organization relevant:
- Look at your company’s annual report. Find key initiatives and risk factors. Create a cheat sheet for your team of the top business priorities.
- Be knowledgeable about IT compliance requirements and regulations. Plan in order to avoid fines, protect your company’s reputation and prevent losing customers.
- Tie IT’s initiatives to what’s important to your business. Focus on how you can positively impact risk, cost, revenue and agility.
- Make meaningful outcomes from the data. Purposefully automate based on the results of the analytics.
- Purchase tools or leverage existing tools. Automate the processes of collecting, analyzing and reporting on exceptions in your environment to get ahead of problems.
- Leverage the information you are collecting. Protect your ability to maintain SLAs and avoid business and compliance risk.
CEO, 21st Century Software
Rebecca has 20-plus years of experience working with clients on storage management, migration and resiliency strategies.
Kristin Lewotsky is a freelance technology writer based in Amherst, NH. More →
Sponsored ContentAchieve Compliance Without Impacting Productivity
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus