Tips for Updating Hybrid IT Security Policies: Act Now

By Mark Houpt, Chief Information Security Officer, DataBank

Constant Changes Require Regular Policy Reviews

Change is constant in the world of IT. The same should hold true for your security policies. Any time your IT environment changes, it’s imperative to review your security policies practices before the IT changes. This will ensure that your IT systems are aligned with corporate and general best security practices that will curtail or prevent unwanted intrusions.

Perhaps, you plan to migrate from an on-premises architecture to a colocation scenario. You might also want to set up remote users or turn to a hybrid situation that includes public and private cloud platforms. No matter which changes you contemplate, it’s time to look at your security policies. The new architecture could impact your security posture and audits for regulatory requirements. You also need to know if your enterprise can still operate within the current policies or make the necessary changes that allow the business processes to function while protecting your data and digital assets. Assure that a gap analysis is part of a security assessment in which all the policies still work effectively inside the new environment. This environment may include another data center operator (colocation or managed services provider) handling some of the workload, while other functions may remain on premises or move to a cloud platform.

Determine the Impact of Moving Data

When infrastructure changes occur, companies may not understand the impact of the new environment and what they need to change with respect to security policies and data protection.

First, determine which regulations you are required to follow, such as PCI-DSS, HIPAA, and other privacy regulations. Then run an analysis, called a Business Impact Analysis (BIA), to determine the impact of moving data into the new environment. This includes considering what measures to implement to protect data to which the new colocation or cloud provider potentially has access.

You may determine, for example, that you want to use a different encryption level. If you are subject to HIPAA, you may need to have a Business Associate agreement that addresses the activities and responsibilities of your service provider partner. Be sure to look at the regulatory and business drivers as well as the requirements within your organization — legally and within business processes — that allow or disallow the use of the new environment. For example, data sovereignty, or the location of data, is an important factor in many regulations, especially those that are assigned by a State or the Federal Government.

Collaborate with Internal and External Resources

It’s a good idea to regularly connect and interface with partners with whom you share security responsibilities. This includes your auditors, vendors (and their subcontractors), and customers to find out how the new environment will affect their audits:

● Will it impact whether you pass audits?
● Will the cost or the length of time to complete audits increase?
● Does the changing environment impact the number of documents auditors will request?
● Is there a responsibilities matrix that defines which party is responsible for each aspect of the environment?

Also, collaborate with your internal business units as well. How will their processes and data be impacted when accessing systems inside the new environment? What’s the impact on the security postures of the environments in which they operate?

Perhaps, your most important allies are your colocation and cloud providers. This involves discussing their responsibility matrix, which influences how your security policies might need to change. The matrix outlines who is responsible for implementing, managing, and maintaining specific cybersecurity controls under the Cybersecurity Maturity Model Certification (CMMC) 2.0 program and the National Institute of Standards and Technology (NIST) SP 800-171 publication.

The provider may assume some of the security responsibilities for you, or it could put new responsibilities on your plate. For example, a colocation provider or a cloud provider will take on a portion of the physical security of the data center where the data resides. However, that doesn’t remove the security requirement from you totally; you still have people accessing that data on the back end.

It’s important to identify exactly what each provider delivers for security measures and what it claims are your responsibilities. Then check what the provider’s audits say and how they perform against those audits. Are there exceptions? Are there weaknesses that might create a vulnerability within your organization?

The Team Approach to Building Strong Security Policies

DataBank consults with many customers on our colocation environments and other environments to which our data centers connect. We clearly identify our security responsibilities and make our services easy to consume, taking the worry out of IT, as much as possible, within the security requirements. We also point out where the customer is responsible and where their cloud and SaaS providers are responsible.

In some cases, we participate in group calls with our customers and their other providers to understand where each party’s responsibilities begin and end. We offer our expertise and interact in a collaborative way to help all the parties in each customer’s ecosystem ensure the implementation of strong security policies.

This is helpful when discussing the transmission of data between colocation sites and a cloud platform. A colocation provider is not responsible for securing data transmissions. However, we recommend that our customers use AES-256 encryption or better for data at rest and in transit. If the cloud provider won’t handle the encryption, we can advise the customer how to configure the encryption.

Security Policy Recommendations for Government Data

In one case, we worked with an enterprise customer that handled federal government data. One of their on-premises data centers kept crashing, so they wanted to create a hybrid environment to share the workload.

To solve this challenge, we moved part of the infrastructure inside one of our colocation data centers, and the uptime increased. We also offered our expertise on the boundary line requirements. In addition, the customer valued our interpretation of the FedRAMP and FISMA requirements for handling data and maintaining the security of that data from physical and logical perspectives.

For customers not going through a change to their infrastructure, we still recommend reviewing and updating their security policies at least annually, even if just to confirm which systems are still active. In some cases, reviews should occur more frequently. For instance, enterprises should review artificial intelligence policies for security every quarter. The technology and the overall concepts change so rapidly.

When reviewing physical security policies, the concepts haven’t changed dramatically in years. You can validate the policy on an annual basis.

Developing a Security Policy Manual

Our information security policy standards manual update involves looking at all the regulations we need to comply with to determine which one is the most reasonable and the most stringent. We set our policies across the board at the most relevant and the most business applicable model and raise the bar when a regulation or situation dictates a higher control.

That’s because we don’t want to have a negative impact on the business. The regulation we conform to might not be the most stringent, but it is the most relevant to our environment. And then we have everything else comply under that unless there’s an item that’s a unicorn.

We set our policies for the NIST 800-53 Rev. 5 moderate level. However, if there’s a situation where we need to meet high criteria, we write a policy that takes us to that level for that specific matter. This occurs with penetration testing as an example. The NIST 800-53 moderate level says we need to conduct a penetration test only once per year. But PCI-DSS compels us to run these tests twice each year. The other standards are met by the moderate baseline, and then that one is bumped up to meet the PCI-DSS requirement.

Always remember: If you just migrated to a hybrid IT environment, or anytime you make changes to your infrastructure, the time to review and change your security policies is before and after the move. One ensures that your policies are up to date and ready, the other ensures that the policies are adhered to. Otherwise, you run the risk of a breach that could lead to the loss of data or regulatory violations.