Compliant or Complacent? A Security Pro’s Viewpoint

Increased government regulations and industry requirements are forcing organizations to comply with standards that in the long run are actually very useful. Many of the required controls can seriously help improve your security posture – especially if your company is new to compliance.

The compliance trap that many companies fall into is that they focus on passing an audit instead of ensuring a sound network security posture.  Being compliant is one thing, but being secure is a completely different level.

As we’ve seen in the news recently there have been multiple companies that were compliant (and possibly complacent), yet not secure. Achieving compliance should not be the end-all-be-all of your security program; it should be viewed as a minimum baseline.

Point-in-time vs. Continuous Compliance
Regulations and standards are needed to help keep information technology and security teams (and the business) honest. If you’re just looking to pass an audit you’re failing as a security professional. While the entire business fails in a way, it’s your responsibility to educate management and fight for better security, not just meeting compliance requirements. The purpose of an audit is to determine if you’re adhering to the standards of said regulation(s), but you can be compliant at the time of an audit and fall out of compliance post-audit. Being compliant doesn’t mean that you’re compliant only when the auditors are in the building – it must be continuous.

This is something that drives security professionals crazy, because inevitably there’s always a mad dash to “verify” and “prove” that you’ve been following the defined controls during the year when the auditors show up. The check box mentality is dangerous because it lulls engineers and especially management into a false sense of security. What much of upper management and even engineers see is process and technology being put into place to assist with security. So the prevailing thought is that we must be secure, but in reality these are security basics, not a proverbial impenetrable fortress.  Security managers must not let people fall asleep behind the wheel and continue to build on top of the foundation that the regulation/requirement has just laid.

Using Compliance to Build Upon Your Security Program
Here are some key considerations for you to use “compliance” as a method for building up the security of your organization.

1. Go Get Budget! Compliance helps get the attention of senior management (non-compliance can be quite pricey in terms of penalties, fines and bad headlines). Use compliance as a way to grab their attention to open up the coffers.
2. Use Technology to its Fullest! Beyond hopefully getting some more funds thrown at a security program under the veil of ensuring compliance, you must make sure you’re using the purchased technology and resources to their full potential. For example, there’s been quite a bit of discussion in the past week on the value of a firewall (see “Why You Don’t Need a Firewall” and “Taking Issue with Article on Why You Don’t Need a Firewall”). The use of firewalls are often required as a control within a security regulation, however if they’re poorly managed, the value they can provide is diminished. We can’t fall back into the check-box mentality after we implement a firewall, we need to make sure the rules are configured properly, that egress filtering is applied, that it’s being patched appropriately, etc.
3. Process, process, process! Following process is not only a great way to keep things in order in security, but can be used company wide and should be used as a cornerstone with other “non-compliance” related topics. One thing that regulations demand and auditors look for is sound process that is actually followed. Creating the framework for policy review will not only help you with firewall rule changes, but with building a larger change management process that encompasses your entire infrastructure. Getting these type of processes rolled out companywide are the building blocks that we’re talking about and once you have them established you can start adding to them to incorporate risk, emergencies, and any other variable that’s prudent.
4. Compliance should be the minimum baseline of your security program! If you’re new to compliance there might be large steps needed in order to get to a place that you’re considered “compliant”, but you should never go backwards. Keep building your posture off of compliance requirements, but build it for security not to address a regulation. If you do this from the start, compliance will just fall in line. If you aim to just be compliant you’re par for the course (any golfers out there?), you’re average and sooner or later you’re going to get beat. We all know that it only takes one incident to be compromised, so why don’t we aim for a little higher than average security.

So compliance can be a double-edged sword – it can give you a false sense of security or it can be used as the impetus behind building your security program and building confidence from the business in your information security department. It’s your choice, choose wisely.