Tip

Security and compliance can go together, when done in the right order

We hear a lot of people clamoring about being compliant with this law or that regulation, but are they really? When it comes to actually having security and compliance, we're talking about an entirely different issue.


Kevin Beaver

The executives and compliance managers in the financial organizations that recently have made the Privacy Rights Clearinghouse

    Requires Free Membership to View

Chronology of Data Breaches would probably agree. I am sure they were saying, "We have to comply with GLBA, PCI DSS, FFIEC and other regulations, so we're confident our systems are secure." If it were only that simple.

Let's use the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule as an example for comparing compliant with secure. GLBA's first element is: "Designate an employee or employees to coordinate your information security program." Anyone can claim he is responsible for information security oversight.

GLBA's second requirement is: "Identify reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information … such a risk assessment should include consideration of risks in each relevant area of your operations, including: (1) Employee training and management; (2) Information systems, including network and software design, as well as information processing, storage, transmission and disposal; and (3) Detecting, preventing and responding to attacks, intrusions, or other systems failures."

What looks good to auditors

This sounds fancy and many claim to be doing these very things. For instance, many financial organizations have employee training programs specifically on security and privacy. I've seen many companies go to extreme measures to ensure that protecting sensitive financial information is on the top of everyone's mind. After all, it looks good in the eyes of the auditors.

But again, they may be compliant with GLBA, but are they secure? Not hardly. Just because employees are told what to do and not to do doesn't mean that someone isn't going to unintentionally mess up. Nor does it mean that someone having financial trouble at home isn't going to do something for ill-gotten gains. It also doesn't mean the network administrator is getting the right training so he can stay on top of things and use technology to enforce the rules.

Regarding GLBA's "…network and software design" and "…detecting, preventing and responding to attacks, intrusions, or other systems failures," it's easy to trust that firewalls, intrusion prevention and other access controls are going to keep the bad guys out -- especially if your hosting provider and software developers tell you everything's secure. They simply present an audit report or the results of a security scan and chock up another one for "compliance."

"Compliance" can be hazardous to your business

But that still doesn't mean your systems are secure. You show me a data center that's compliant with this or that standard and has state-of-the-art monitoring run by technical engineers who continually manage and harden your systems, and I'll show you numerous Web applications that can be hacked, servers that can be brought to their knees and humans who are making mistakes. To believe that everything's secure just because technologies are in place or a vendor touts a seal of approval or certification and subsequently promises that you'll be compliant with GLBA, PCI, etc., can be hazardous to your business.

Let's look at the GLBA Safeguard Rule's final requirement: "Evaluate and adjust your information security program in light of the results of the testing and monitoring required by paragraph (c) of this section; any material changes to your operations or business arrangements; or any other circumstances that you know or have reason to know may have a material impact on your information security program."

For some reason, many people seem to cut off their compliance efforts once they do their initial risk assessment and put the necessary controls and documentation in place. We assume that all's going to be well indefinitely from that point on but, eventually, we find ourselves back into our old ways and our systems in disrepair.

Anything worth having is worth maintaining, and your information systems are no different. Unless you can say that all reasonable checks on your network infrastructure, wireless systems, Web applications, operating systems, databases, storage systems, mobile devices, people and physical systems have been made -- and are being performed on a periodic and consistent basis -- odds are near 100% that's there's something big that can be exploited for malicious purposes. It's simply a matter of time.

To-do list

If you're a financial manager faced with GLBA Safeguards Rule compliance, here are the things you should be doing to make sure your sensitive financial information is protected:

  • Review the Standards for Safeguarding Customer Information.

  • Determine how you can integrate GLBA compliance with other compliance initiatives (odds are they're all covering the same -- or similar -- issues).

  • Find out where your information systems and IT operations are weak.

  • Plug the holes you find and put some basic controls and processes in place to ensure ongoing security and compliance.

  • Assess and validate your security on an ongoing and consistent basis.

When the HIPAA security and privacy rules were becoming popular in the early 2000s I would tell people you can have security without privacy but you cannot have privacy without security. The same goes for compliance: You can have security and still not be in compliance, but you absolutely cannot have true compliance without real security. So the moral of the story is don't ever assume (and don't ever let someone tell you) that your information systems are secure just because your organization is in compliance with whatever law or industry regulation. It's just not true.

Kevin Beaver is an information security consultant and expert witness, as well as a seminar leader and keynote speaker at Atlanta-based Principle Logic LLC. He can be reached at www.principlelogic.com.

This was first published in September 2009

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.