Twitter Facebook Linkedin

Creating and Sustaining a Positive Security Culture – By: Seth Kulakow

To share...Tweet about this on TwitterShare on FacebookEmail this to someoneShare on LinkedInShare on StumbleUpon

Author: Seth Kulakow, CSO

A CSO’s personal experience in successfully creating and sustaining a positive security culture.

I have spoken at many different security conferences throughout my professional career.  Without fail, there were always post-speech questions involving some type of internal personality issue related to security and an approach to it.   It didn’t take long before I started to notice a pattern that I too had confronted, but was able to successfully address with some initial simple strategies.  Below, I will discuss why a positive security culture is a critical component of a successful security program.  In addition, I will provide a series of how-to steps to understand and address a negative security culture.

In an instant, an incident(s) could wipe out trust and confidence in a security program that may have taken years to build and sustain.  I have seen this many times throughout my career.  I argue that a negative security culture is the singularly most disruptive influence to a successful security program, period.  A negative security culture fosters mistrust at all company levels, creating preventable budget and resources obstructions, poor security team morale and turnover, enormous effort in simple task completion, and a much higher overall enterprise risk posture. Though it might seem unfair and unsound, security culture has its own set of constantly changing complex judgments and is in need of constant care and feeding.  I have found that creating and sustaining a positive culture is a major undertaking but without it a security program is destined to fail.  With that said, let me introduce my how-to steps to discovering and creating a security culture that is collaborative and positive.

Step 1: Establish An Initial Group Framework

First and foremost, it is really important to understand what your internal cultural landscape looks like.  This isn’t easy as one could have many distinctive cultures whether large, small, internal, or external.  Before any analysis begins, I must first construct a framework, comprised of only a few High and Main level groupings (as shown below). To do this, I form only two high level internal and external categories, followed by five main sub-categories.  Note: I tend to have about five separate Main group categories as this helps prevent analysis through paralysis and complexity.

Groupings

SKulakow-Groupings-Small

The goal here is to only build a simple initial framework.  In the future as the security culture matures, (which could be over a year or more), the framework becomes much more complex by creating smaller Minor Sub-Groups, as emerging patterns require a different approach to the larger grouping.

Step 2:  Main Sub-Grouping Tracking

After framing out my High and Main level classes, I focus my attention to just internal main groups, as they pose the largest security risks.  Don’t worry; often, I usually experience parallel positive maturity growth in both internal and external groups as company wide trust in security elevates consequently impacting external groups.  Next, I use or create a tracking tool, such as a spreadsheet, with Main Sub-Groups separated into different worksheets (as shown below).

 

SKulakow-TrackingSpreadsheet.jpg

Step 3: Ask Two Essential Security Program Questions

Up to this point, there hasn’t been any data gathering or analyses just framework construction, where I could associate and track my findings.  Now, I need to find out about my internal culture.  I accomplish this by only asking my groups two simple, but critical questions (shown below).  Please take a little time to consider method(s) for question delivery and response as it is absolutely urgent to get correct, as this might be many individuals first real interaction with a security team member. Tip:  don’t circulate questions via email.  I have had much more success by handing it out in small organized 10 minute (time allowance for questions and answers) meetings (10 or fewer people from the same main sub-group); it makes it much more personal.     Note:  prior to surveying the enterprise, I present the same questions to my internal security team, not only to see if they are in alignment with each other, but to make sure I have consensus regarding answers to both questions.  In about a week, I re-meet with a group where I start gathering and organizing my findings into the spreadsheet (created in Step 2).  I again meet with small groups in an effort to create an open forum and drive honest results.  Also note:  this step often marks the onset transition to a positive culture cultivated by to face-to-face meetings.

  1. What do you think the function or role of security is?
  2. What do you think security encompasses or covers?

 

Step 4:  Do An Alignment Analysis

I find this to be the most interesting step in the process, as I finally can get a sense of where my culture exists.  If answers are not closely aligned, which is often the case, I know I will have to expend a big effort to educate and align my internal community.  In addition to alignment, if answers from group members are partially or not completed and or much of an effort put forth, this is another indication of poor security culture.  Without going into to much detail regarding the tracking spreadsheet, as results come in, I try an update it on a daily basis.  It will be a pretty obvious correlation of Groups with low point totals to security culture issues.  Warning:  it is very important at this point not to be too reactionary by abruptly adjusting from a high level to a more granular focused approach, as this can bring the entire course of action to a halt (analysis paralysis).  As I mentioned above, Minor Sub-Group immersion is a future undertaking as frameworks, foundations, and positive momentum must be rooted and be viewed as well organized.; prove it before you ask for more.

Is this misalignment or lack of response that big a deal?  Yes!  Until this is done, one will most likely have large barriers to justifying budget and resources; thus, negatively impacting trust and the ability of the security program to mature (just to name a few).

Step 5:  Start The Alignment Fix

Not to state the obvious, but misalignment should be addressed immediately.  I recommend starting with a communication campaign, encompassing benefits, roles, and requirements (such as regulations if applicable) of the security program.  Based on my experience, to achieve general alignment might take four months to a year if properly focused.  I suggest a combination of the following: emails, training videos, small group Q&A sessions, posters, quarterly surveys, and an incentive program that rewards employees for their general secure program knowledge (I have found small face-to-face Q&A sessions to be the most successful).

Step 6:  Determine Your Existing Security Team Culture

Let’s recap a little.  I first created a foundation framework.  Second, I assessed the knowledge of the environment.  Now is the last major step; to understand the culture that surrounds the security team through a two-step process.  I have come up with another framework to help.  It consists of five general classifications (shown below) and associated characteristics with rankings from worst (largest security program risk) to best, as follows:

  1. Uncompromising

  • Security Team Characteristics:
    • The prevailing “It’s my way or no way” atmosphere lacks any impact analysis or compromise;
    • Staff members use scare tactics, such as “the sky is falling”, to mask their short comings;
    • Team Members were inherited (moved) to security position, not based on experience but because they were considered a “bad apple”;
    • Members insist upon having full administrator access to all systems;
    • There is constant daily incident firefighting; Members hide, don’t, and/or fear conveying significant risk issues to upper management;
    • Internal team communication and collaboration are repeatedly ineffective as members generally work in silos and at times on the same task without each others’ knowledge, often resulting in redundancy, ad hoc security standards and requirements;
    • Each individual member has their own limited access file share.
  • Security Program Characteristics:
    • Missing structure and transparency;
    • Few written security policies, standards, processes, and procedures;
    • Missing foundational components, such as standard templates, forms, secure storage, and team network file share;
    • Purchased tools often “sit on the shelf” or remain in a Proof of Concept (PoC) stage, either due to missing skill sets or time to implement;
    • In-use controls are often in poor condition ;
    • Written metrics do not exist;
    • Incident handling is unstructured and ad hoc;
    • Resources are limited and waste is high. Controls are focused on “cool” technology solutions and were purchased without any requirements generation.
  • General Security Culture:
    • May not even exist or is poorly understood, perceived as a hindrance, and or of no substantive value;
    • Is not understood by Executive management, which, not, and views program as only a contractual or compliance check with little to no trust or confidence in the security staff and program;
    • Has no oversight– Security team feels it can do whatever it wants and gets away with anything;
    • Can’t control Non-security employees who frequently and intentionally bypass security controls; Likewise, Security team doesn’t listen or try to understand non-security team requirements, resulting in non-communication between them;

  2. Hallway/whisper

  • Security Team Characteristics:
    • Challenges still occur but confidence in competency is starting to increase, usually due to hiring (or removing/replacing), staff training, and/or upper management efforts to assist. Please note: team staff size generally stays around the same as a new hire is usually a replacement fill and not a net gain.
    • The general tone of “It’s my way or no way” stance without any impact analysis or compromise endures;
    • Team moral takes a positive spin upwards as team’s new abilities are “marketed” to upper management;
    • Some staff members still use scare tactics, such as “the sky is falling;
    • Most members insist upon having full administrator access to all systems;
    • Some team cohesion fractures start to arise as only new hires receive work praise from external teams, thus spawning petty jealousies;
    • Some members constantly complain of “too many” and “no time”, relating to projects and workloads as work is often ad hoc;
    • Weekly incident firefighting happens but full team participation isn’t always necessary;
    • Internal team communication and collaboration start to form as internal recurring meetings are created and duplicative work effort issues are being addressed; problem still occurs but not as common;
    • Some members start to gravitate to specific role functions such as incident response or engineering/architecture roles.
    • All members still create ad hoc security standards and requirements but there is a new impetus and understanding towards creating projects to actually document requirements.
  • Security Program Characteristics:
    • Program is still considered immature but structure and transparency are beginning to happen for the first time;
    • Few written security policies, standards, processes, and procedures;
    • Non-security employees frequently and intentionally bypass security controls;
    • Existing controls’ assessments launch;
    • Security specific network share is setup as a collaboration and standards tool repository with all team members having access, but usefulness not well understood or practiced;
    • Some ad hoc analysis of existing “on the shelf” or PoC stage tools is initiated by newer team members (without management ask) as an effort to stabilize security infrastructure;
    • Work intake is completely ad hoc and is completed on a “first come, first served” basis;
    • Initial transparency actualizes as new budget asks by security are coming under increased executive scrutiny due to existing tool duplications and prior mismanagement;
    • Incident handling is unstructured but basic roles are somewhat accepted and understood;
    • Basic high level written metrics are started but not consistently gathered or acted upon.
  • General Security Culture:
    • Small pockets of trust are established but perception still a hindrance, and or of no substantive value. Executives start to show interest in program but mainly in a negative manner;
    • Typically, issues are brought to the security team via “unusual” means like ad hoc hallway meetings or in passing with one “trusted” security staff member;
    • Generally, security team still doesn’t listen or try to understand non-security teams requisites;
    • Security’s role and function within the company is still not understood with employees frequently and intentionally bypass security controls.

 

  3. Office visit/Email Contact

  • Security Team Characteristics:
    • Examples of daily team cohesion personify a growing confidence with team’s overall competency, communication, and trust (members offer assistance to others without being asked). However, collaboration and consensus building are still not fully practiced;
    • Parts of team have hands-on multiple discipline experience but do not voluntarily offer cross discipline training to other members;
    • Team organization progresses to where incoming work is beginning to follow a standard intake processes paired with templates, impact analysis, system access requirements, and compromise;
    • Management starts to address member complaints of “too many” and “no time” by creating task/project prioritizations based on a formal risk process;
    • Ad hoc security standards and requirements continue to spring up but there is a new impetus to actually document requirements;
    • Unknown projects and tool implementations are still frequently occurring but are not intentional and mostly due to missing change and project management practices and communication;
    • New resource asks take an up tick abilities frequently identify newly found, long existing issues;
  • Security Program Characteristics:
    • High level program structure and transparency begins with defined roles and responsibly, work intake process, attempted focused metric data gathering and analysis, executive management program status reporting, budget framework setup, etc.;
    • High level general security policies, standards, processes, and procedures are written and made available to all company employees without formal training;
    • A full effort to analyze existing controls and tools is underway as part of a gap analysis;
    • Incidents are being handled in a basic structured framework in addition to the advent of a cross organizational incident response team but without training, structure, and role comprehension;
    • Budget ask is much higher as tool analyses discover issues and gaps are coming to light more frequently;
    • Considerable time and effort is spent justifying program wants in order to overcome negative opinions due to past budget waste and program ineffectiveness thus impacting program maturity growth;
    • Executive level program updating occurs but not on a set schedule and with rare feedback;
    • A formal risk management framework is attempted;
    • Basic high level written metrics are gathered but not consistently acted on;
  • General Security Culture:
    • A basic general overall trust kicks off as security staff is looked upon as assets? willing to listen, compromise, and generally provide useful assistance. For example, security team members are frequently asked to assist with troubleshooting non-security related issues;
    • There is moderate executive support; executives believe security is a must. However, an aura of mistrust prevails primarily due to the belief that prior program investment did not product expected value;
    • Security ‘s role, function, controls and policies are mainly not understood but viewed as “probably important” thus not intentionally bypassed or ignored;
    • Typically, issues are brought to the security team via email and or impromptu meetings accompanied by “I am sorry for the short notice but I couldn’t wait for the security team to get involved” and “next time, I will try to keep you in the loop sooner”.

 

 4. Trusted Adviser –

  • Security Team Characteristics:
    • Team is a well-educated, multi-disciplined experienced group and is often involved with other non-security related activities such as general troubleshooting;
    • Each team member is considered a strong asset but time is scarce due to significant impacts from new projects, tools, and/or for general advice solicitations;
    • Internal team begins challenging and comparing each others knowledge and proficiency;
    • Team members are cross trained in multiple security disciplines in order to provide resource redundancy;
    • Team is quick to identify, alert, educate, and address new gaps or issues on their own initiative.
    • Team insists and preaches adherence to standard program processes and procedures regarding projects and tasks;
    • Some team members have an understanding of what comprises a mature security program stating obvious;
    • Team cohesion is strong with established trust across multiple roles and responsibilities based on constant collaboration, communication, and practical consensus;
    • Some members experience legitimate time issues as workloads are overstretched by additional non-security commitments;
    • Some members feel that their careers won’t progress as desired roles are already filled and or have lost some motivation to self learn leading to some turnover;
    • On occasion, team loudly expresses frustration related to projects they were not aware.
  • Security Program Characteristics:
    • Strong program structure and transparency should exist. Policies are specific and call out associated standards, procedures, and HR ramifications if not adhered too. Metrics are granular, well defined, analyzed, predictable, and acted on. Business continuity planning begins with the onset of Business Continuity Plan (BRP).  A formal risk management framework is routinely exercised and issues are quickly conveyed to executive management.  Security is still not mandated as part of project inception stages.
    • Almost all program controls are in place, well documented, functioning, supportable, redundant, and sustainable but not necessarily part of a System Development Life Cycle (SDLC) program (this also includes staffing needs);
    • Incidents are always handled in a structured, consistent, and documented, framework with routine scheduled incident team exercises and cross role backup;
    • External events are monitored and analyzed for possible negative impact;
    • Program resources and budgeting are somewhat predictable and do not require significant time and effort due to a strong overall trust;
    • Mature components of the program are complete such as 3rd party/vendor assessments and management. Plans; however a full security awareness program exists but entirely effective as program updates and scheduled notifications are not adhered too.
  • General Security Culture:
    • A strong trust and bond is established as security team takes the time to understand and collaboratively assist across many different functional areas to advise;
    • Security staff are looked upon as major assets who are helpful, knowledgeable, rarely say “no”; they also have full executive management backing;
    • Most non-security employees are active participants in everyday security;
    • Security’s role, function, importance, controls and policies are understood and welcomed;
    • Management embraces security as a trusted partner.

 

  5. Pro-active

  • Security Team Characteristics:
    • Internal team consistently challenges and compares each others knowledge and proficiency;
    • Some team members leave possibly due to other career opportunities but also due to daily repetition;
    • Standard security processes/procedures and standards are always followed;
    • Team members often work outside of their normal role.
  • Security Program Characteristics:
    • Program structure and transparency exist and are consistently tested by internal team and 3rd parties in order to find and fix any gaps;
    • A strong SDLC process is followed regarding security tools;
    • Security is a mandatory facet of project inception stages;
    • Controls are consistently tested for redundancy;
    • A Business Recovery Plan is fully tested and functioning;
    • Mature components of the program are complete such as 3rd party/vendor assessments and management along with security awareness.
  • General Security Culture:
    • The saying “Security is only as strong as your weakest link” is well understood throughout the company;
    • Non-security employees are active participants in everyday security;
    • There is full executive security program support as executives are intimately involved with program collaboration and direction;
    • Projects are not released into an environment without security team project sign-off.

In determining classification ranking, I recommend the following two methods.  First, create a security team focused-survey with questions that can all be answered with a Yes or No (an example is shown below):

  • Do you feel the security team provides value?
  • Do you fully trust the security team with safeguarding company IT assets?
  • Do you feel the security team is transparent regarding security incidents or issues?
  • Does the security team respond to your needs or do they come across as arrogant?
  • Does the security team properly explain why they made a security-related decision which/when it conflicted with your opinion?

Keep the survey non-technical and have maybe five or fewer questions.  Again, I recommend handing out and answering in one meeting (if you feel that it isn’t too much, add Step 3 questions and extend the meeting a little longer) instead of email to foster relationships and answer specific questions on the survey if they arise (most people, if not too busy, will look at five questions right away).  Yes, a mass email can get it out to more people but the goal isn’t number of responses but well thought-out responses.

Second, set a period of time aside (such as a couple of hours three times a week for a month) to observe how security staff conducts business.  For example, if meetings with other groups are normally contentious or unproductive with minimal to no attendance, I will know (rather fast) my classification level, without waiting for many survey results.   Note:  it is important to periodically use observation as a tool to trend security culture levels (people get tired of surveys pretty fast).

Conclusion

I know how daunting and overwhelming it can be to take over a security program.  I have spent sleepless nights pondering what should I do first, only to have the following days’ issues create an about face on my well set plans.  I have had moments where I finally felt my program was making progress only to be proven wrong, for a myriad of reasons.  There were so many ebbs and flows that it can be very disheartening as if you are trying to refuel a plan in flight.  I am often approached by overwhelmed security program managers unsure about where to start.  Without hesitation, I almost always state discover and cultivate a positive security culture to support your security program; stabilize the patient first before healing can occur.  Without that positive security culture, it will be impossible to build and sustain a successful security program.

I want to sincerely thank you for your time and allowing me to share some of my thoughts.  I would also like your feedback to hear what your thoughts are. Below, I have posed four feedback questions to you.  I certainly can understand if you feel uncomfortable answering any of the questions.  However, I will not share specifics (such as name and company), but I will report back on overall responses. Please feel free to reach me at the following email:  seth.kulakow@gmail.com.

Does culture currently pose a huge problem for you?

  1. Do you know what culture currently exists at your company?
  2. Based on the five levels of culture where do you think your company’s culture is?
  3. What experiences would you be willing to share regarding culture issues and how you faced and beat those challenges?
  4. Would you recommend any changes or additions to this initial methodology?

Thank you again for your time!

To share...Tweet about this on TwitterShare on FacebookEmail this to someoneShare on LinkedInShare on StumbleUpon
Seth Kulakow

About Seth Kulakow

Seth has a proven track record as a technology leader and trusted advisor with 15+ years of experience delivering dynamic and secure business solutions. He has a unique, hybrid background of diverse managerial and technical roles extending into numerous industry sectors such as Healthcare, Government, and Transportation.