In my time as a Security Consultant, I’ve had the pleasure of seeing first-hand varying levels of maturity in information security programs. I’ve seen programs that work really well and I’ve seen some that could use quite a bit of maturing. In this blog, I’m going to attempt to identify programs that work well and how their success is achieved.

Compliance Focused Program

I have rarely seen a security program succeed when it is solely focused on meeting requirements enforced by some sort of compliance body. Don’t get me wrong, compliance should always be a part of a security program but should not be the main motivation for a security program. I’ve witnessed a lot of compliance driven programs that put compliance at the forefront of security decision making and fail for several reasons. Two of the most common ways these programs fail are described in detail below.

  1. The CSO/CISO position reports to the CIO/CTO.
    • This presents a conflict of interest, which often forces the CIO/CTO to approve/disapprove requests from the CSO/CISO based on whether or not the request will check a box on a compliance report. It also places decision-making at the whim of the CIO/CTO’s own initiatives for his or her team, which may conflict with the CSO/CISO’s initiatives.
  2. Compliance language isn’t very clear most of the time.
    • I’ve witnessed programs that did what they thought they were supposed to do, based on their understanding of the compliance language, in order to pass a compliance assessment. When it came time for the penetration assessment portion of the compliance requirements, however, it was evident there were gaping holes in the security. I’ve seen this lead to reports resulting in non-compliance because there were too many medium level or higher risk findings, and the company didn’t have the capacity to remediate.

Security Focused Program

This may come as a surprise to many of you, but a security program solely focused on security typically fails as well. The reasons for failure are very similar to those of a solely compliance focused program with a few differences.

  1. CIO/CTO reports to the CISO/CSO.
    • This produces a conflict of interest on the other side of the equation. The CSO/CISO will make approval/disapproval decisions for requests provided by the CTO/CIO based on security initiatives which may conflict with the CTO/CIO’s initiatives for bettering the IT group.
  2. If there is too much security, employees will work hard to find ways around the system (think password sticky notes in easy to find places on desks, whiteboards, etc.).
    • Resources almost become unusable by normal users within the company. This leads to decreased productivity, loss of employee engagement, and worse, frustration leading to employee departure.

Risk Management Approach

Approaching an information security program with risk management in mind seems to yield the most successful results. There are, however, better ways for implementing a program with risk management as the central focus. Successful programs that I have seen exhibit the following characteristics.

  1. CISO/CSO and CIO/CTO both report to the CEO AND have a well-established trust relationship.
    • This benefits the organization as a whole because it shows support from the top of the leadership hierarchy, and it shows a trust that the security program will focus on risk reduction meeting many organizational initiatives, not just one person’s agenda. I had the pleasure of working under this type of organization at one point in my career, and the amount of authority granted to the security group was like nothing I’ve ever seen. In this situation, the security group is trusted to approve or disapprove projects if the project is deemed to introduce too much risk into the organization. With that said, it’s expected that the security group will work with the various project teams to correct any outstanding items helping them reduce their project’s risk to an acceptable level. This works well when the people involved get along and are focused on the betterment of the organization, not departmental agendas. Final approval of all projects goes up to the CSO/CISO desk with the security group’s recommendations.
  2. Risk Reduction more often than not leads to passing compliance audits.
    • Think about this one for a minute. If a security program is focused on reducing risk, more likely than not the organization will take steps to implement best practice procedures, policies and standards. This will then lead to easily passing compliance audits because the emphasis will be on implementing practices that minimize risk. I’ve seen this work very well for both small and large organizations.

Tips for Effective Risk Management

  1. Identify assets – both hard and soft.
  2. Identify known risks.
    • This can be done with a risk assessment once assets have been identified.
  3. Identify unknown risk.
    • This can be accomplished with various forms of security assessments (penetration assessments, application security assessments, architecture assessments, etc.).
  4. Prioritize remediation based on risk identification.
    • Focus on either remediation based risk rating of assessment findings, or likelihood of exploitation (this may be different for different organizations based on business type/model)
    • Focus on risk elimination when possible, and risk reduction when elimination isn’t possible. Deferring or transferring risk should be the last resort once efforts to eliminate and reduce risk have been implemented.).
  5. Repeat steps 1-5.

Once an organization has a handle on risk management, and it becomes an ongoing process and not a one-time figure-it-out type of moment, then other components of a mature security program can come into play. These include compliance audits, frequent policy/standards/process reviews and end user security training. As long as risk management is the central focus of the security organization, the other pieces will be easier to put in place.

The above list should make up the components of a good security program. At the end of the day, it comes down to putting egos aside and understanding security’s niche in the organization, designed to help reduce risks associated with technology, people and the information that the organization processes or stores.

It’s time we move past the mentality that security folks are out to hinder the business process and be an expensive part of the operation. We also need to start educating CEOs that trusting in the executives responsible for technology and information security helps solidify the organization’s longevity, and is a worthwhile effort in relationship building and maturing the organization. It’s completely OK if you, as a CEO, don’t understand anything about security. It’s not OK if you don’t trust the people you hired that do. I fully understand that not knowing can be portrayed negatively in some organizations. Let’s move past this mindset and turn it into a strength by admitting the lack of knowledge and the need to hire smarter people than ourselves so that we can trust their advice. This not only makes for a great security program, but a healthy leadership mindset which results in a healthy organization.