security-conf-logo1Looking forward, make sure you set aside May 14-15 for the Rocky Mountain Information Security Conference. Planning for the 2014 event is well underway. The conference is the premier information security event in the Denver region. The local chapters of ISSA and ISACA join together to put on this two-day conference with full-day training, multiple session tracks, dozens of security-focused vendors, and 600+ members of the Denver information security and IT audit community. The call for papers and sponsorship opportunities is currently open. You can view more here.

Staffing for security and compliance
can present some perilous decisions

By Robb Reck

tug

T

here is a natural tendency to lump security and compliance together. Intuitively, it just makes sense, right? The biggest compliance frameworks — like PCI, GLBA, SOX and HIPAA — are all looking to ensure that our security is up to snuff. In fact, if we do security right, compliance should come naturally, with very little additional technical work. With all these factors in mind, it would seem to make perfect sense to have the same folks who handle your security also handle your compliance. Depending on your organization, however, this may be a big mistake.

What’s the harm? Obviously, these two functions require many of the same skill sets, vocabulary and supportive technologies. Why wouldn’t we want to combine them to achieve efficiencies?

First, a question for you: Would you say that your organization is currently overstaffed, understaffed, or staffed just right?

Understaffed teams supporting more and more compliance regulations. Something has to give.

If you said overstaffed, congratulations, you’re one of the lucky ones. According to CompTIA 52 percent of organizations are understaffed by at least 5 percent in their technical areas. At the same time, compliance requirements are growing at an astounding rate. You can do the math on this. We are requiring already understaffed teams to support an ever-growing pool of security technologies and an ever-increasing library of compliance requirements. Something has to give, right?

Let’s role-play a bit. Put yourself in the shoes of a decision maker within an organization that supports both security and compliance. You’ve got enough resources to support one of the following:

  • Implementing a web proxy solution that will allow your security team to view the content of encrypted traffic going to and from the organization. While not perfect, this solution will provide greatly improved information assurance, both proactively preventing the leakage of sensitive information and giving a valuable tool to perform forensics on breaches that may have already occurred. Or ...
  • Implementing a new Web Application Firewall (WAF) to stand in front of your PCI-DSS web servers. Your organization doesn’t really know how to implement or support a WAF, but this is a neat technology that we’ve heard a lot about.

From a security perspective, one could argue which of these solutions is more valuable. There are certainly arguments to be made on both sides.

A web proxy provides previously unrealized visibility into employee behaviors. A WAF, meanwhile, can provide additional application security. But if it’s not properly configured, tuned and monitored, it provides minimal or no value.

We must avoid pitting security against compliance projects, or security will never be achieved.

Now throw in the fact that your company is an online retailer and the entire business model is predicated on accepting credit cards. By implementing a WAF, you can get through that pesky PCI assessment and continue accepting credit cards. All of a sudden the decision becomes easy, doesn’t it?

This example is pretty stark and many are not quite so obvious. But the general point holds true. By lumping security and compliance responsibility into the same area, security will continually take a back-seat and fail to receive the resources to make a truly excellent security program. These little trade-offs are what make the difference between a secure organization and a compliance organization.

No, I am not suggesting that separating security from compliance staff is right for every company. In small to medium businesses there are simply not enough resources to create an entirely different department for each. But in every size organization we should at least consider the functions of security and compliance separately.

How do we do that? As you consider what projects to fund, do your best to divide initiatives into either “Security” or “Compliance.” Then compare projects to others within their own group. Whenever possible, security initiatives should have their own budget. This way, we’re making decisions about which security project to fund rather than just funding the top compliance project every year.

In many organizations this will require a dramatic shift in focus. We must intentionally and deliberately avoid the dichotomy of “security versus compliance” during funding conversations. Otherwise, we will choose compliance far too often.

Share