Pipeline Security Automation

This post talks about how we approach security automation in BitBucket Pipelines. It also introduces some new open source tools we built and use in the process.

Security In Pipelines

We’ve written before about using GitHub Actions and provided an Action friendly “workflow” with our Crush tool.

At a high level, Pipelines and Actions just do some computing work for you in Atlassian or Github’s data center. Often that work is related to source code, testing, or deployment.

Both leverage containers heavily for sandboxing the work that happens in the build and provide some level of abstraction that you can use to build your own pipes or workflows.

On some level, we’re using them to do the same work we used to use Jenkins or CircleCI or Travis to do.

We like automating security in Pipelines or Actions because it makes it easy to build security into your natural development workflows.

Real World

So what are we really talking about? What do we want to have happen?

We want to be able to apply any automated tools flexibly in a controlled environment that already has our code artifacts and knows about the key events.

Triggers for actions and pipelines can be:

The tools we want to run may range from:

Of course, we can run security unit tests and trigger other integrations (eg. SonarCloud) as well.

Just remember:

Tools are necessary but must be used by skilled operators.

I can’t tell you how often I see security tools installed but not used effectively.

OK Show Us Code

Here is an example of how we have a pipeline configured:

    - parallel:
      - step:
          name: Run Crush
          image: golang:1.16
            - go get -u github.com/jemurai/crush@v1.0.5
            - crush examine --threshold 7 . > crush.json
            - crush.json
      - step:
          name: Dep Check
          image: openjdk:8
            - wget https://github.com/jeremylong/DependencyCheck/releases/download/v6.1.5/dependency-check-6.1.5-release.zip
            - unzip dependency-check-6.1.5-release.zip
            - rm dependency-check-6.1.5-release.zip
            - ./dependency-check/bin/dependency-check.sh --failOnCVSS 6 --exclude **/dependency-check/**/*.jar -f JSON --prettyPrint --scan .
            - dependency-check-report.json
    - step:
        name: Report
        image: golang:1.16
          - go get -u github.com/jemurai/depcheck2off@v1.0.0
          - go get -u github.com/jemurai/off2jira@v1.0.0
          - depcheck2off ./dependency-check-report.json > ./depcheck.off.json
          - off2jira ./depcheck.off.json
          - off2jira ./crush.json

Let’s walk through it and talk about what is happening.

First, the branches part tells BitBucket when to run the pipeline. In this case, it will be on any push to a branch under securityautomation.


We like doing this because it helps to isolate your security related chnages and ensures that what you are finding doesn’t break other builds. In the long run, we want to have security tooling run more often.

Then we need to understand that there are three steps defined in the pipeline:

Crush and Depenendency Check are both code analysis so they can run in parallel. Hence the parallel: before their step: definitions.

To run Crush, we pull a base golang image image: golang:1.16, install Crush and run it. We drop the output into an artifact that means it will be available later.

- step:
    name: Run Crush
    image: golang:1.16
        - go get -u github.com/jemurai/crush@v1.0.5
        - crush examine --threshold 7 . > crush.json
        - crush.json

Running Dependency Check is similar. You can see that we’re pulling a release from GitHub and unzipping it. This is on an openjdk image. Then we invoke dependency check and put the report in an artifact.

- step:
    name: Dep Check
    image: openjdk:8
        - wget https://github.com/jeremylong/DependencyCheck/releases/download/v6.1.5/dependency-check-6.1.5-release.zip
        - unzip dependency-check-6.1.5-release.zip
        - rm dependency-check-6.1.5-release.zip
        - ./dependency-check/bin/dependency-check.sh --failOnCVSS 6 --exclude **/dependency-check/**/*.jar -f JSON --prettyPrint --scan .
        - dependency-check-report.json

The next part “Report” is interesting and we’re going to put it in a whole new section.

Reporting and Rethinking Security Tooling

Once we have Crush and Dependency Check output, we want to do something with it. We could leave it in BitBucket as an artifact and refer to the plain text file. That is better than not running the tools, but we also want make these visible and integrate into our normal processes.

Here’s how that looks in the pipeline we defined where we’re pushing the issues identified by Crush and OWASP Dependency Check to JIRA:

- step:
    name: Report
    image: golang:1.16
       - go get -u github.com/jemurai/depcheck2off@v1.0.0
       - go get -u github.com/jemurai/off2jira@v1.0.0
       - depcheck2off ./dependency-check-report.json > ./depcheck.off.json
       - off2jira ./depcheck.off.json
       - off2jira ./crush.json

Here we are installing and using two new golang based tools:

The basic philosophy is to build small tools that do one thing and do it in a simple and predictable way. This goes directly against our own past approach with OWASP Glue which we retired.

With Glue, you could run different tools and push the output to a variety of trackers. The problem was that you ended up with a JVM, Python, Ruby, Node and an ever growing docker image. That made it hard to incorporate into pipelines efficiently. We also had to maintain everything and keep everything working to get an update pushed. It was a monolith.

With the Jemurai autom8d set of tools, we’re taking more of a classic Unix philosophy and building small purpose built utilities that can be put together in a number of ways.

So far we have:

We already have plans to build:

We also want to adapt and integrate some other code we have that does an inventory and metrics across repositories.

We’d love to hear from you about others that would be useful! We can help with this type of automation while doing so with open tooling you can leverage for the long term.

Leverage Pipelines

The great thing about pipelines (and actions) is that once you understand them, you can effectively push security tooling to a large number of projects quite easily.

Note that there are compute charges associated with running pipelines (or actions).

We have also had good success helping companies who leverage BitBucket or GitHub cloud because we can actually help commit the code that starts the autoamtion project off. Combined with some training and a retained ongoing support setup - we can enable clients to very quickly improve their internal app security posture.


Getting Ready For A SOC 2 Audit

If you’re a product or service organization that handles client data, you should seriously consider getting a SOC 2 audit. Larger companies that contract your services often require having a SOC 2 audit report to do business with them.

More importantly, though, you’ll need to develop a security program that addresses the security challenges of handling client data. SOC 2 compliance is a framework that helps you do that. The SOC 2 standard organizes its data security requirements into five trust service criteria (TSCs): security, availability, process integrity, confidentiality, and privacy. We go into detail about the SOC 2 standard itself here. Now, let’s talk about the SOC 2 audit process and how to prepare for it.

How to Choose An Auditor

How your SOC 2 audit turns out largely depends on the auditor. Some have sophisticated knowledge about information security and others, well, don’t. We always prefer to work with auditors experienced in information security. An auditor who doesn’t actually understand security can’t speak to what really matters—namely, whether the security controls you have in place genuinely address the trust service criteria. An auditor who can only check boxes that a control does or does not map to a certain TSC or that a control test did/did not show expected results (an “exception”) isn’t much help. For example, such an auditor can’t assess whether you have compensating controls in place that reduce the risk of an exception. An auditor with a strong grasp of security can make those determinations, which directly impacts whether the audit results in a qualified, unbiased opinion (which is what you want).

When looking for an experienced SOC auditor, ask whether they’ve audited companies similar to yours, specifically in terms of company size and level of security maturity. If your industry has a specialized set of security risks, it’s even more important that the audit firm has worked with other companies in your industry.

Many firms use multiple auditors in a layered review. Find out what the auditor firm’s process is. They may have junior auditors do the initial review who don’t yet have the experience to properly identify and address exceptions. However, the firm could still be a good fit if it uses senior auditors with which you can have constructive conversations as a second review layer.

In addition to experience, we also value auditors who are transparent about what they’re going to ask for and how they operate. If you don’t feel a sense of transparency from them in response to your qualifying questions about their experience and process, it is possible they won’t be forthcoming during the audit process.

Some of our clients chose to go with the “big name” audit firms because they audit major companies like Salesforce and Google. They feel these auditors are a safe option, because who’s going to question their expertise? They’ll pay for that safety, of course, as audits by the big firms can cost $100,000 or more.

You don’t need to spend six figures on your SOC 2 audit, but you also don’t want to choose an auditor solely on price either. A “cheap” SOC 2 audit can be around $25,000, but that’s likely a small firm that lacks the security sophistication you want your auditor to have. We refer clients to five reputable audit firms, ranging from medium to large and specialized.

What You Need For Your Audit

To put it bluntly, you will need documentation and lots of it. Your documentation starts as a result of developing security policies and processes to secure your and your customers’ data. You’ll need additional documentation that demonstrates how your company consistently applies and communicates its security policies and procedures. Change management documentation regarding your security policies and information security environment will also be necessary.

You may need documentation of how you regularly test and validate your controls and policies. If you’re engaging in a SOC 2 Type 2 audit, you’ll need to provide documentation of test results over a period of time, typically six to 12 months, showing how your controls hold up over time. A SOC 2 Type 1 report validates that you have controls and policies in place as of a specific date.

You’ll have to prepare a System Description, which AICPA breaks down the System Description into nine “description criteria” categories:

The above is not an exhaustive list of the documentation you’ll need for a SOC 2 audit. However, if you’re approaching information security right, much of the documentation needed will be a natural output of building a strong security program.

There are tools that can help automate evidence gathering and preparation, which can make preparing for an audit less onerous, but they can’t do the job on their own. For example, you can run a tool to document how permissions are organized and applied. However, if you want to know that permissions for a given application are set-up correctly, you need to know what the application does and who should have what type of access. A tool can’t make that assessment. The tools leveraged by the SPIO platform to collect and document evidence needed for an audit do speed up the process, but we always advise clients to use them in the context of human judgement.

Who Inside Your Organization Needs To Be Involved?

You definitely want a senior person to provide executive oversight. We recommend appointing someone with budget authority to take responsibility for company security as a valuable first step in improving your company’s security (it is one of 21 actions your company can take to improve its security fast). Depending on personnel available, this person could also be the one who coordinates all SOC 2 audit activities.

IT staff and others in more junior roles can pull together the documentation and other evidence that you’ll need to provide to the auditors. If you have dedicated security personnel, like asecurity DevOps engineer, they’ll certainly be involved. These personnel are key to showing how your security program can detect and respond to security events.

A clear, well-written System Description will be helpful, so you’ll need someone with writing skills and strong knowledge of information security. As with other assistance in preparing for a SOC 2 audit, you can outsource writing the System Description, say by using the SPIO platform and Virtual CISO services.

As you think about the actual audit process, it is useful to know how much time the auditing firm expects you to spend with them.  From our observation, it usually requires an ongoing commitment of 2-8 hours per week during preparation and then a fairly full two weeks of time during the audit period.  Many audits involve a week of evidence gathering meetings that require not only the leader but also the company expert in the particular meeting topic who can help collect evidence.

Understanding The SOC 2 Audit Process

While SOC 2 has five trust service criteria, you don’t need to include all five in your SOC compliance program. Security is the “common criteria” that’s part of all SOC 2 audits. You can stop with that criterion, but you will have to explain why your security program and SOC audit don’t include the other four TSCs in your System Description. The more TSCs you include in your audit, the more valuable your SOC 2 report will be. Further, as a service provider, some of your potential clients and partners may specify what TSCs your SOC 2 report needs to cover.

As for the SOC 2 audit itself, there’s a formal, highly recommended path you can follow:

While following this framework can be quite involved, it’s a good model for assuring that controls are in place to achieve security growth as fast as possible, while also building a body of evidence regarding their implementation.

A SOC 2 Audit Shouldn't Be A Paper Chase

When you do consider getting a SOC 2 audit, don’t think of it simply as obtaining a report with a stamp of approval. You can always find auditors who take that approach, but it won’t be a meaningful path towards building a mature security program that impresses potential partners.

You may be motivated in the moment because a client or your sales team is telling you having a SOC 2 audit report is necessary. Yet the report won’t matter much if it doesn’t reflect a substantive security program that can, in fact, protect your clients’ data. Practical security is the goal, and the carefully prepared documentation and reporting are a critical means to that end.

Your Next(or First) Security Hire Should Be...

For years, a common rule-of-thumb said your security spending should be around 10% of your company’s IT budget—but that rule doesn’t quite hold up anymore. In fact, a 2020 Deloitte survey on cybersecurity says this number is now more like 10.9% and rising year after year. That’s not surprising, as cyberattacks keep getting more sophisticated, and more companies of all sizes get targeted. There may be significant accumulated technical debt for those organizations that have not spent that needed 10% for security over the last few years.

For most smaller companies, that 10 or 11% means you can't hire additional FTE security people until you have at least 200 employees, and even then, you have to be very selective. So, when you’re ready, how should you approach hiring in-house, full-time security personnel? We shared our thoughts on who your first security hire should be here. The TLDR on that is: It depends on a lot of factors, but it should probably be a DevOps person. A skilled DevOps person can code and automate tasks that will help you make the most of the security platform tools that do the heavy lifting of your security program.

One of our clients recently hired several security personnel. They started by hiring a chief information security officer (CISO). They followed that by hiring a security engineer, followed by a governance, risk and compliance (GRC) officer, then an application security engineer, and finally a DevOps person.

That’s a pretty sizable security team for a small company, and it means they’re spending more on security than most companies of their size. Most SMBs and start-ups can’t afford this kind of security team, even if they do ignore the 10% rule. Further, those roles might not even be the types of immediate security hires that makes sense for them.

How you invest resources in security will vary depending on the risks, profile, and priorities of your company. Planning a security hiring roadmap is a bit like growing your security program, and it starts with an analysis of your company’s needs.


When you focus on your risk priorities, you can think broadly about the most effective way to address them. Should you bring on a new hire, outsource to a security service provider, or invest in software tools or external SaaS security platforms?

For example, due to its industry one of our corporate clients is a ripe target for specific types of fraud, including bot automation and account takeover. They hired employees who focus on preventing these types of fraud by mapping application paths and defining new “speed bumps” against these types of attacks. In their case, building in-house security expertise on the threats specific to their business is a smart investment. They can use a combination of outsourcing and security tools to address the more common security issues that all companies face.

Speaking of which, one of the most common security controls all companies need to implement is endpoint security. Because endpoint security is a universal, high-priority security need, it has a well-developed ecosystem of tools and service providers to which companies can outsource this task. Consequently, we usually see small companies either task their existing IT personnel to managing the endpoint tools or outsourcing it to an IT firm.

Another universal risk area is network architecture, configuration, and monitoring. If you have IT personnel with strong network skills and experience, they can use a proper set of network security tools to manage scanning and monitoring the network for vulnerabilities or intrusions. If your first security hire was an experienced DevOps coder, they can write scripts to leverage these tools to improve the company’s ability to detect, analyze, and respond to risks in (and threats to) your network infrastructure. Of course, network management and monitoring can be and often is outsourced entirely. Network monitoring is a 24/7 job, which requires multiple personnel, even when automation is handling the rote and scale tasks. For this reason, outsourcing can be less expensive for a small company than building a 24/7 monitoring team in-house.

The most common scenario is for small companies to use a combination of tools, staff, and outsourcing to meet the full scope of their cybersecurity needs. Another client—one with high privacy requirements due to the nature of the data it handles—leverages the SPIO platform to continually mature its security program. At the same time, it also works with an outside privacy security consultant and assigns task execution responsibilities to an internal DevOps team. Through this combination, the company benefits from SPIO security expertise to grow their security program, while plugging in additional privacy expertise specifically targeted to their industry’s domain.


In our post on your first security hire, we discussed the challenges of balancing senior leadership experience with practical task experience in a more junior role. We stick by our recommendation of starting with practical DevOps experience for your first security hire or two. Their functional expertise means they can leverage both security tools and outsourced expertise to put your company quickly into a strong security posture.

However, you will need somebody in senior management with authority to oversee company IT security. Identifying that senior person is one of the 21 steps your company can take to immediately improve its security posture. Senior IT security responsibilities can initially be delegated to the head of IT, the risk management/GRC officer, or your vendor management team. These employees may not have the practical security experience, but that’s why it is important that your first dedicated security hires do.

While it can be a challenge for a small but growing company, you want to bring on someone with senior IT security experience as early as possible, so your security program develops and operates strategically rather than tactically. Remember that, even if you bring this person into a hybrid security role, their experience enables them to best leverage security compliance management software like SPIO and third-party security experts for a well-rounded security program. As your company expands and starts looking at working with bigger companies with more stringent security expectations, it will work to your advantage to have someone with seniority who can talk confidently with prospects about your company’s security program.

Companies getting serious about security should start small

A security program takes time to build. But you need one, no matter the size of your company, so, if you have to, start small. It's better than procrastinating and leaving your company vulnerable.

Starting small means making some security decisions that you can act on immediately. We'll help you out with that in the next section. As you put in place some common security protocols, you can start thinking about how to turn these first steps into a formal security program. We recommend building a security program incrementally by working through a framework provided by a recognized security standard. 

This approach keeps you moving forward without feeling overwhelmed. Your team will learn more about information security and gain confidence along the way. As you do, you'll grow your security program into something more robust. We generally work with two security standards that are valuable starting points for building a security program incrementally:

We’ll share more on both below. But first, let’s get you some quick security wins.


You can strengthen your company's security before you even write your first security policy. Some security steps are universally valuable and easily implemented, and they are the perfect place to start making small yet meaningful steps to improve your company's security posture.

If you complete these five steps over the next few weeks, you'll already have raised your company's security posture exponentially:

  1. Choose one person and make them responsible for company security; someone with budget and authority to advocate and effect change
  2. Train employees on the risks of using poor passwords as well as how to recognize phishing or social engineering attempts
  3. Create and enforce a password handling security policy that enforces best practices for password management, such as requiring multi-factor authentication (MFA) on your most critical systems
  4. Review which users have access to which system and capabilities and then applying the principle of Least Privilege (granting users the minimum access and permissions required to perform their jobs)
  5. Install endpoint protection software on all devices that connect to your network; it should include anti-virus, anti-malware, and anti-ransomware protection

These are only five of the 21 steps we've identified that you can take to immediately improve company security. You can download the guise and start working through all 21 security quick start steps. As you do, you can also start assessing which security standard you want to use as the framework to build a full security program.

NIST 800-53

The Security Program platform was designed around NIST 800-53 because it’s such a robust and flexible standard. It covers a large group of domains and controls but also provides guidance and a methodology for conducting analysis and making security decisions.

We like it as a baseline standard because so many other security standards draw on the domains and controls included in NIST 800-53. As your company completes more security tasks based on 800-53, you’re also raising your compliance level with other valuable security standards.

One of the challenges with 800-53 is that it’s so comprehensive. Its breadth can stymie companies without experience in information security or creating a security program. Working through 800-53 using a compliance management software platform like Security Program can provide the expertise and support needed to break it down into manageable chunks. You can check out a more detailed explanation on why we use NIST 800-53 as our base-level security standard and how it helps small companies grow strong security programs.

Some small or new companies prefer to start with a more targeted standard. For those companies, we recommend starting with CIS Controls®, which is a nice on-ramp to NIST 800-53.


The  Center for Internet Security (CIS) is an industry organization dedicated to helping people and companies improve their online security. Formerly known as "CIS 20" because it had a list of 20 controls, the current version has a list of 18 controls. That reflects a re-organization of its control families, not a narrowing of its scope. In fact, the most recent version of the CIS Controls has expanded to include security for mobile and cloud technologies.

The CIS Controls are built to reach organizations and people without information security experience and to help them prioritize actions that protect them against their most likely risks. They're written in plain language with a description under each control explaining why it's critical. The documentation presents specific actions ("safeguards") companies can take to implement each control.

The standard provides precise guidance to companies by dividing them into implementation groups (IGs). The three IGs are defined by organization size, security expertise, risk tolerance, and budget. IG1 covers small businesses with a low risk tolerance, tighter budgets, and little security experience. IG3 covers highly regulated enterprises that manage sensitive data, and where there’s risk to public welfare in case of a successful attack.

Each safeguard is marked to show which IGs should implement it. For example, control 2 covers inventory and control of software assets. It has a total of seven safeguards, three of which are marked for IG1. All the safeguards under all the controls are marked for IG3 organizations. In this way, the CIS Controls provide a clear, incremental roadmap. These safeguards and controls are also mapped to other common standards, including NIST 800-53.

The Data Breach Investigation Report (DBIR) references the CIS Controls specifically to reflect which controls are most valuable given actual threat data collected in the report. This mapping includes specifying the most useful CIS Controls by industry, given that industry’s most prevalent threats. The DBIR also identifies four controls as a “core set of Controls that every organization should consider implementing regardless of size and budget:”


And by “grow,” we’re talking about your security program and your business.

Somebody said every journey starts with a single step. That’s how your business started. You can approach security the same way. Starting small is fine, but you do need to get started. You won’t be able to scale up operations responsibly or expand your market without a solid security program in place. Let your security program grow with you. It’s not a journey you need to take alone. Whether you want to start working through NIST 800-53 task buckets or start slower with CIS Controls, the Security Program platform and team are here and can help walk you through it.

Five Things You're Not Doing That Put Your Data at Risk

The gravest risk to your data is taking an ad hoc approach to security instead of implementing a carefully thought-out security program. Creating a security policy requires assessing risk and making decisions on how to mitigate it. Selecting security controls requires going through a process to find tools and techniques to execute and enforce your security policies. There’s no real security without deliberate action. That’s why ad hoc security won’t work.

If you are relying on ad hoc security, here are five common vulnerabilities you probably aren’t addressing.


Unpatched systems and applications are like open doorways into your network for bad actors. Most system patches exist to fill in a known and documented security gap. Hence, an unpatched system or application is the easiest vulnerability for hackers to exploit yet one of the simplest to eliminate.

A review of security metrics found "13.4% of all critical risks discovered in 2020 related to unpatched, unsupported or out-of-date systems." The research also found that hackers are attacking companies through common vulnerabilities and exposures (CVEs) that are years old and for which patches have long been available.

To cut your company's risk of CVE exploitation, automate your patch management. Patch management software can continually scan your system to identify unpatched vulnerabilities and can often automatically install the available patch or alert you so you can make the decision. It can also identify and report patches that require your manual installation. Finally, make sure you rank those systems and applications which should get the highest priority for patches and updates. 


Having a system or device on your network that you aren't actively managing is dangerous. Unmanaged infrastructure isn’t monitored for suspicious activity and thus rarely receives patches or upgrades unless someone happens to think about it. If you don't know a device or system is connected to or running on your network, you can't manage, monitor, or patch it.

Unfortunately, it’s pretty easy to understand why you’d have an unknown device or application—or many of them—on your network. Perhaps it's underutilized or obsolete, or maybe it was never approved in the first place. As newer infrastructure gets installed, earlier systems and computers are forgotten. Out of sight, out of mind.

The use of unapproved devices or applications—often referred to as "shadow IT"— presents a clear security threat when connected to the company's network. Bring-your-own-device (BYOD) programs were already growing pre-pandemic, but work-from-home (WFH) has expanded the number of non-corporate devices connecting to your network daily. The risk is more than just devices, though, it is software. Thanks to the growth in cloud-based SaaS solutions and mobile apps—often with low monthly subscription costs that don't trigger approval requirements—it is easy for employees to select applications outside of approved channels.

Companies need an array of security policies and controls to stay on top of underutilized, obsolete, or unapproved systems and software. To start, you should regularly run a network scan tool that inventories all the devices and applications on your network.


You might find it hard to believe, but the most common password in 2021 is "123456." You can find a list of the most common passwords here, but you can bet hackers already know them. There's simply no excuse for weak passwords. Unfortunately, we can't begin to tell you how many hacks happen due to weak credentials. 

Hackers exploit weak passwords through brute force attacks or password spraying. In a brute force attack, the hacker uses a program that keeps trying common passwords to get into an account. Password spraying is an expanded brute force attack that targets many accounts at once. Hackers also guess weak passwords using personal information publicly available, stolen, or gathered through phishing.

Hackers then exploit weak passwords to collect more credentials. They can look for stored credentials in the system and steal that data. One hacker forum hosts a file with an estimated 8.2 billion stolen credentials. Hackers also use a compromised account to send out credential phishing emails to others.

Whenever possible, your company should use multi-factor authentication (MFA), which blocks access even if the hacker breaks the password. In addition, you should train users on solid password generation and management techniques. Using a password management system makes it easier for users who only need to remember one passphrase. Finally, train users to identify a phishing or social engineering communication so they don’t inadvertently divulge their access credentials. 


In almost every deep analysis we do, we find system users performing actions they shouldn't be able to do or accessing data they shouldn't be able to access. It's the difference between authentication and authorization. Too many companies have insufficient authorization schemes because they conflate it with authentication.

Authentication is when a user proves to the system that they are who they say they are, often via usernames and passwords or biometrics like facial or fingerprint recognition. On the other hand, authorization defines the scope and type of access that a user has in a specific system. For example, an unauthorized user could be someone who was inadvertently given:

Without setting a security policy on how system authorizations are determined and managed, you increase the risk that a user will have technical authorization to systems and data they shouldn't. 

To limit this risk, adopt a security policy to take a "least privilege" approach to authorization. A user should get no more access or authority within a system than needed to fulfill their role. A simple example is denying everyone other than the accounting team from accessing payroll systems and then only the minimum access they need to do their jobs.

Weak authorization schemes also increase the risk of a privilege escalation attack. During a privilege escalation attack, the hacker uses access to one account or system to grant themselves even greater access. The hacker can try to use it to access another system or take administrative control of the system they've already compromised. Privilege escalation also occurs by hacking a known bug or vulnerability to gain initial access—another reason to stay on top of patching and software updates.


Given the danger from ransomware attacks, every company should be concerned about their critical data and systems. Ransomware attacks grew by 150% in 2020, and there’s no sign it will let up soon.

It can be perilous to rely on negotiating or paying a ransom to regain access to your data or systems. A recent analysis of ransomware attacks shows that more companies are paying ransoms—one significant reason attacks keep rising—but only 8% of them got back all their data.

Start with a security policy that sets guidelines for defining tiers for categorizing data and systems by priority. Then, you can determine additional security policies and controls for each tier. All your data should be backed up and stored on media offsite and unconnected to your network. You may decide to use disk mirroring for systems relying on your most critical data, so all that data is written in multiple places as it is created or updated.

In some cases, the attack locks you out of the system rather than encrypting your data. In this case, a business continuity plan is vital for bringing your systems back online if your primary environment is compromised.


The foundation of a comprehensive security program is conducting a risk analysis to identify your company’s particular vulnerabilities. Taking steps like inventorying all devices, systems, and user authorizations is part of a risk analysis. You also want to ask questions like:

Conducting a risk analysis is more detailed than this, but it’s necessary to implement a security program that addresses your company’s specific risks. Once you have identified and categorized high risks and fraud paths, then you can identify the metrics that you can use to detect anomalies before an attack.


Addressing these six vulnerabilities is a good start, but any list like this is necessarily a bit reductionist. There are so many security issues to be considered and addressed that the process of conducting a risk analysis and making security policy decisions is ongoing and evolving. Companies need to move away from ad hoc security and start building a security program that can mature over time. Without a security program in place, they aren’t just putting their network and digital assets at risk, but they’re throwing up red flags to potential partners.

Maintaining Business Continuity in the Face of a Cyber-Attack

Molson Coors suffered a cyber-attack on March 11, 2021, that disrupted "its brewery operations, production, and shipments." By early April, the company reported to investors the company still wasn't operating at full capacity. In contrast, meatpacking giant JBS was able to recover operations quickly after bad actors attacked its servers. JBS shut down plants in three countries after hackers launched their attack on a Sunday, but it reported most plants back online by the following Wednesday.

The difference between the two? It comes down to the level of business continuity planning. A company's ability to continue essential functions during an attack—and quickly resume full operations afterward—is critical to minimizing the direct and indirect costs of the attack.

When it comes to being prepared for the expected, every organization—regardless of size— needs some level of business continuity planning. However, business continuity today is about more than just surviving a natural disaster or the loss of key personnel. According to the 2021 Data Breach Investigations Report (DBIR), small companies are nearly as likely to suffer a security breach as large companies. That's why your security program must address business operational continuity in the face of an active attack as well as how to recover fully once the incident is over.

The length of downtime a company suffers is a critical factor in how destructive the attack will be to a company's revenue, resources, and reputation. For example, in one survey, 40% of SMB respondents said they experienced at least eight hours of downtime due to a cyber breach. The average cost of that downtime was $1.56 million.

The goal of your security program's business continuity plan is to keep as much of your company operational as possible during an attack. This could mean protecting essential assets and functions not yet compromised by the attack. For those that are compromised, it means getting them back online quickly—in an alternate location, if necessary—even as the attack remains active. 


Business continuity in the face of a cyber-attack is largely dependent on decisions your company made before the attack. 

When setting up your security program, an early task is to identify what data, infrastructure, and functions are mission-critical. These are the assets that should get the highest level of protection from your security policies and controls. Yet, as part of your security program, a business continuity plan must go beyond mere asset protection. It must outline the steps and infrastructure for recovery, failover options, and other contingencies to minimize operational downtime. 

As you make security policy and control decisions, business continuity needs to be part of the analysis. Here are a few key considerations:

Access management: Deciding how you'll manage to access your data and systems is critical to your company's ability to contain the reach of a hacker. A privileged access management (PAM) policy is the most restrictive approach regarding access and rights. Depending on the controls used, PAM can restrict access not only by user account but also prevent that user from further access to other systems. For example, suppose a bad actor hacks into a lower priority application on your network. In that case, PAM can prevent him from using that application to gain access to more critical areas of your network.

Data recovery: Ransomware attacks are growing. You can't minimize downtime by negotiating with (and waiting around for) an attacker to return control of your data. Instead, you can regain quicker access to your data by having daily data backups stored somewhere outside your company network. However, you may decide even daily backups are insufficient for some of your most important data. If losing a day's worth of your data is too much, you might choose to install disk mirroring for some systems.

Network diversity and redundancy: If you lose access to a critical system or function due to an incident, you need systems and controls in place that allow you to quickly switch or failover that function to a different part of your network or an unconnected network. Segmenting or virtualizing parts of your network can create secure places to which you can divert systems traffic or re-establish functionality.

Mobile devices: Stolen or lost mobile devices are a prime vulnerability for most companies. A PAM policy and controls can keep your network operational if an external device such as a smartphone is compromised. You may also create a security policy that enables remote wiping of any mobile devices with access to a business application or data.

These are only a few parts of your security program where you must consider business continuity needs. You can consult the NIST 800-53 security framework for more information on developing these and other contingency systems to strengthen your company's resiliency during a cyber-attack.


Business continuity and incident response are closely related and need close coordination, but they are not the same. Not every incident presents a severe or catastrophic threat to business continuity. Threat level assessment, which includes determining the scope and severity of an incident, needs guidelines that define when particular business continuity protocol(s) should be triggered.

The primary area where incident response and business continuity overlap during an incident is containment. Once a threat is detected and assessed, the first goal should be to contain it. A typical incident response for containing a severe threat is to take other systems offline. However, from a business perspective, this action means the organization loses access to the data and systems directly attacked and those taken offline as a defensive measure.

The business continuity portion of your security plan should focus on measures that shift the attacked and vulnerable operations, data, and systems into a safe mode. Having redundant, failover, and backup systems in place—whether on-premise or in the cloud—can facilitate this shift and get critical operational systems up and running with minimal downtime. Without such planning, your options for rapid recovery are limited, slower, and more costly to implement and likely will not provide as much operational or data recovery as you need or want.

Smooth crisis communication between the incident response and business continuity teams is critical. The communication plan covers how they communicate and collaborate on deciding which actions are appropriate, including specifying containment and recovery objectives, sharing realistic timelines for reaching those objectives, and providing ongoing updates. They also need to coordinate communications with employees, clients, and other stakeholders. The communication plan also needs to address the need for alternate communication channels should an attack compromise day-to-day channels.

Business continuity functions are also responsible for securing assets and business functions not compromised by the attack. Depending on the response plan, this may be accomplished by heightening the barriers between affected and unaffected systems, or by shifting the still-operational systems along with recovered assets and functions to alternative networks and workflows until the threat has passed.


Whether the crisis is a natural disaster or a cyber-attack, a strong business continuity plan allows your organization and its operations to quickly adapt to a threat, thereby minimizing business interruption, downtime, and costs. The longer critical data or systems remain unavailable, the more significant the impact on revenue and reputation, which both constitute long-term threats to your business's future.

Ransomware Attacks and Small Businesses

Ransomware attacks are big news right now. According to US Secretary of Homeland Security Alejandro Mayorkas, ransomware attacks are up a whopping 300% over the last year. Sadly, major pipelines and meatpacking plants and their million-dollar ransoms are just two mid-2021 examples of how serious these attacks are becoming to our critical infrastructure.

However, an even more disturbing story is the growth of the ransomware industry that puts all organizations at risk. Every organization must take the threat of a ransomware attack seriously—small businesses won’t get overlooked because of their size. In fact, 50% to 70% of ransomware attacks target small and medium-sized enterprises.

The same ransomware group that attacked JBS Foods also recently attacked Sol Oriens, a small consulting firm. The hacker group has since published confidential employee data to its blog on the dark web. It also threatens future disclosures, which it declares it has a right to do because the company “did not take all necessary action to protect personal data of their employees and software developments for partner companies.”

Professional service firms, government contractors, healthcare, high-tech companies, and local governments are popular ransomware targets, but attackers can strike any type of organization. Even the Saint Elizabeth Ann Seton Catholic Church and School in Wichita, Kansas, recently became a ransomware victim.


The first step of a ransomware attack is for a bad actor to gain access to where they shouldn’t be. After that, they could attack anything from a single laptop to an entire network, even cloud services. Often they pivot from an initial entry point to an internal reconnaissance stage where they might get a foothold on many or most machines across a network.

During the attack, bad actors use ransomware code to encrypt files, data, and whatever else it can access through the compromised device. Depending on the scope of their access, they may also lock down access to a single system or an entire network. The hackers don’t have to infiltrate the entire network or access the most sensitive data to cause damage. In many cases, victims shut down other systems to protect themselves while investigating and planning the scope of their attack.

Once hackers are in control, they send the ransom note. When the ransom is paid, they’ll provide instructions on how the organization can regain access or decrypt its files. Naturally, they like their ransom paid in cryptocurrencies like Bitcoin because, in theory, it allows the recipient to remain anonymous.


Ransomware is the top malware threat SMBs face, and the costs of a ransomware attack are high. According to a 2020 survey of managed service providers (MSPs), the average ransom hacker demand from SMBs was relatively modest—around $5,600. The higher costs come from the downtime the attack inflicted on the business. For SMBs, the average cost for downtime due to a ransomware attack last year was $274,200, almost 50 times the ransom amount. And for 39% of the small businesses attacked, the downtime was extensive enough to threaten their ongoing viability.

While the average ransom demand may be modest, other surveys found that larger SMBs can get demands exceeding $100,000 and that 50% of all ransomware demands were higher than $50,000.

Ransom payments, downtime, and remediation costs can be quantified, but they aren’t the only costs. There are also costs to the company’s brand, reputation, and relationships. In many cases, client and customer data is at risk in a ransomware attack. In addition, operational disruptions also impact clients. 


Most ransomware attacks come from well-organized cyber gangs. Different ransomware organizations have different targets. Some conduct long-term sophisticated attacks against major corporations, like Colonial, with high ransom demands.

Others operate on volume. They attack smaller businesses that are easier to breach and ask for a ransom proportional to the organization’s size. Balanced against the costs of downtime, potential impact on clients, and risk of public exposure, requesting a reasonable sum increases the likelihood the SMB will pay the ransom.

Under another model, hackers infiltrate a network and sell the compromised network’s encryption key to a second group that carries out the ransomware attack. Ransomware attacks have become so commoditized that some hacker groups actually package “ransomware-as-a-service” (RaaS). Then, they sell the RaaS code to bad actors who don’t have the technical expertise to launch an attack on their own. RaaS and selling decryption keys have expanded the pool of bad actors who can conduct ransomware attacks so that every organization is now—or will soon be—a likely target.

And the ransom payments are only one revenue stream for ransomware attackers. It’s become more common for ransomware hackers to exfiltrate data and sell it on the dark web—not to mention using the data to conduct future attacks.

Bottom line: Ransom attacks are good business for hackers, and we can only expect the rate of attacks to grow.


Phishing is the most common vulnerability used by bad actors to access and lock down a company’s digital assets. They send emails with attachments or links that deliver malware when clicked. Other phishing schemes use sophisticated communication (email or text) and look-alike websites to induce employees to provide login credentials or personal information on what appears to be a legitimate website.

After phishing, the most common attack vectors are:

Once attackers gain entry to the network, they start searching for the most sensitive data. They often operate undetected for extended periods when they’re able to use real credentials. Then, when they feel they have access to enough sensitive data to cause pain, they’ll initiate the ransomware attack.


Protecting usernames and passwords is critical, as the most common attack vectors rely on human error to steal network credentials and gain access. Security policies and other steps you can take to protect credentials include:

Other security policies and software solutions to protect against ransomware attacks should address:

Of course, this is a shortlist of actions. Protecting your company against ransomware attacks requires a formal security program. The ongoing process of developing IT security policies and implementing specific security controls will continue to harden your company against a ransomware attack.


Your security program should include a ransomware incident response plan. In addition, your ongoing security training should include roleplaying a ransomware incident to ensure everyone knows what to do should an attack occur.

So, what are your options once you’ve been attacked?

Pay the ransom. Many companies take this approach to minimize the downtime and impact of the current attack. However, paying the ransom comes with risks. In some cases, companies don’t receive full access to their systems and data despite paying the ransom. In addition, there may be some legal risk to paying or facilitating the payment of a ransom. There’s also the concern that paying the ransom can lead to more attacks, both generally and of the paying company. A recent survey of organizations that paid the ransom found that 80% were victimized in a second attack.

Decrypt your files. With assistance from cybersecurity and decryption experts, you may be able to decrypt your files. However, most ransomware attacks use highly sophisticated encryption algorithms. The time and computing power needed to break them would likely be too high to undo the damage caused by the attack.

Restore files and systems from backups and/or images. A company with a comprehensive backup and disaster recovery plan should be able to restore its data and systems. This doesn’t mean an attack won’t still come with a cost— the mitigation, investigation, and recovery processes all take time. However, it does limit operational downtime and avoids the need to pay the ransom.


Too many small businesses underestimate their chances of being ransomware targets, but this is short-sighted. A small business can be an attractive target as “easy prey” or because of its relationship with a larger, more lucrative, or strategic company or government department.

Now is an excellent time to review your existing security program and IT security policies to see how well your company is defending itself against a potential ransomware attack, as well as reviewing your business continuity plans in case ransomware attackers choose you as a target.

Why we use NIST 800-53 as our base-level Security Standard

The SPIO platform helps small companies build, mature, and document their security programs. We designed the SPIO platform around the NIST 800-53 standard. It's the model for the policies, training, and task buckets we’ve created for our clients to use. Our clients don't have to start with NIST 800-53, but we believe it is a useful jumping off point for most small companies. Using it as the model provides an effective roadmap toward developing a robust security program that complies with many common information security standards.

Here’s why we use it as a baseline standard and how it helps small companies achieve compliance.


First titled "Recommended Security Controls for Federal Information Systems," NIST 800-53 was initially published in 2005. Its purpose was to improve security of the information systems of federal agencies. To achieve this, the publication provided guidelines for selecting and specifying security controls.

NIST 800-53 Rev. 3 (2009) was its first major revision. The changes included updating security control baselines to reflect evolving threats, providing recommendations on prioritization of security controls, and more closely aligning NIST 800-53 with other standards.

As part of its fourth revision, in 2013 the publication was renamed as a Special Publication on "Security and Privacy Controls for Federal Information Systems and Organizations". This revision expanded its scope beyond civilian agencies to the Department of Defense and Intelligence Community. It also expanded the scope of threats addressed. For example, security controls were added to address mobile and cloud computing, supply chain security, and insider threats.

NIST 800-53 Rev. 4 remains in effect until September 23, 2021, when NIST 800-53 Rev. 5 will take effect. The control selection process and baseline sections have been moved to other special publications. Instead, NIST 800-53 Rev. 5 focuses on the control families and controls themselves. The goal in moving selection and baseline guidelines elsewhere is to provide greater flexibility for different organizations in determining which controls to use in their security program.

The updated control families and control list has been re-organized and expanded. For example, there are now control families specifically for privacy and supply chain risk management. Overall, revision 5 has 20 control families (up from 18) and over 1000 controls (up from 800).


It isn't enough to have strong security; your company must also be seen to have strong security.  We wanted our platform to help small companies achieve both. We decided to build our platform so our clients could show third parties that their security program aligns with a well-known security standard.

The question at the time was this: Which widely-accepted security standard do we use? We chose NIST 800-53 because it is:

Broad and comprehensive. Many standards have a narrow focus. For example. SOC 2 applies to service organizations and PCI DSS applies only to credit card transactions. These are valuable security standards within their sphere, but they're too specific to work as a baseline.

Open and accessible. Anyone can download all the NIST publications, including NIST 800-53 and its related publications. Other broad standards, like the ISO standards, come with significant licensing fees. Ultimately, these fees would impact cost accessibility of the platform for small companies. More importantly, openness means everyone knows what's in the NIST standards. Companies can demonstrate their compliance without paying for costly certification or auditor services.

Upstream from many other security standards. Many other common standards are derived from NIST 800-53. CMMC, FedRamp, and NIST 800-171 are just a few. With so many standards flowing from 800-53, it's a strong foundation for achieving compliance with other standards. The SPIO platform maps security tasks across most common standards. So as our clients work through task lists based on 800-53, they see how those tasks map to requirements of other standards.

Prescriptive and flexible. NIST 800-53 and its related publications provide a methodology companies can use to guide their selection of controls and a detailed list of controls. Other standards, like SOC 2, outline the domains that companies must address, but don't offer too much specific guidance on how to do it. NIST 800-53 is designed with a variety of controls so that each company has the latitude to make its individual choices while still remaining within the standard.

Our choice of NIST 800-53 as the SPIO platform base-level standard doesn't mean it's perfect. No security standard is. For example, because it's so broad, it can also seem overwhelming. Companies can avoid the overwhelm by working with a platform like ours, which breaks 800-53 into task buckets they can work through sequentially. On balance, NIST 800-53 creates a solid foundation for establishing and maturing a security program. 


The breadth of NIST 800-53's scope and its extensive list of controls provides a practical roadmap for continuous, incremental security improvement. Making progress through each of its control families strengthens your security posture. Its comprehensiveness ensures that you work through all the critical security questions you need to address.

Meeting the NIST 800-53 standards does more than improve your security program. It also improves your company’s security compliance with a broad range of common security standards. The fact that so many other security standards are downstream from 800-53 means complying with it takes you a long way towards complying with other standards.

Security compliance is the "being seen" part of maintaining a strong program. Potential partners and customers may want to see your level of CMMC compliance, a SOC 2 report, or some other popular security standard. Even those that don't require a formal certification or an audit report often want to see proof of a solid security program that aligns with a well-known standard.

The SPIO compliance management software helps provide that proof.  Each task is cross-referenced with the corresponding requirements in many standards. As your company progresses through tasks based on the NIST 800-53 framework, you're also checking off the aligned requirements in other standards. Your SPIO dashboard shows your progress against all the applicable standards.

If your company does a good job with NIST 800-53, then you've eased your path for certification or passing an audit. Each auditor or certifier has their own interpretation of the control framework and checklist of what they want to see. So, most companies still have some work to do before getting certification or the audit is complete to satisfy the certifier or auditor. The question is how much work?

When you've already made good progress through many of the 800-53 control families, your company will have most of that work done. You don't have to start from scratch when a potential customer wants to see how well you comply with their preferred standard. Nor will you have to suffer extensive delays to prepare for certification or an audit since you’ll have completed so much of the work by complying with NIST 800-53.


Because 800-53 is such a broad standard, we start by assessing our clients’ security goals. Then we have them get started in our system by adopting security policies on different issues. From there, tasks within the 800-53 framework are organized in buckets around those IT security policy areas. This approach lets them build towards their goals over time and in a manageable way.

Sometimes a company really wants to ease into building a security program before jumping into a comprehensive standard like 800-53. In those cases, we start with a small group of well-defined tasks, like setting up multi-factor authentication, setting up a program to track data shared with partners, and conducting employee security awareness training. It’s a core of quick wins that build confidence to move to a more formal, complex security standard.


Meeting requirements of 800-53 provides a solid foundation, but the truth is that managing your security program is an on-going project. You’re never done. But if you start making progress now and grow as the standard and its controls evolve, you will reach a maintenance state. In a maintenance state, you re-assess existing tasks previously completed and add new tasks aligned with new control families. Your company continues to make progress against more standards and raise the quality of its security program.

What is the difference between a security program and security compliance?

When we start talking about security programs and standards, we need to also talk about security compliance. Unfortunately, these terms can start to blur together. To eliminate confusion, we define them here and explain how you will want to use them together to optimize your company’s information security. We also clarify a few other terms along the way.


A security program is the documented collection of policies, controls, and processes used by a company to protect its assets. Let's break this down:

Documenting your security program is essential. Information and cyber security have too many moving parts to rely on an ad hoc approach to security. Documentation is the reference material that keeps the organization aligned with its security decisions.

The core of a security program are its security policies. Each IT security policy sets the expectations in a specific area, like data security or incident response. Collectively, security policies are the roadmap that sets the scope and guidelines of your security program.

Security policies don't specify how they are implemented. Those details are in the controls and processes. They are the mechanisms you choose to put your security policies into practice.

An example: An automated tool (a technology control) conducts weekly user audits to defend against unauthorized access to your network and data. The process around responding and remediating any audit flags is an administrative control.

The purpose of your security program is to protect the confidentiality, integrity, and accessibility of your company’s assets, and to contain and minimize the impact of any intrusions. Define your company assets broadly; you can assign a security priority to different assets once you define and identify them. Your assets are data, intellectual property, strategic documents, business processes, and the network that supports your ability to operate.

A security program is the culmination of internal analyses and decisions regarding where your vulnerabilities are, what your risk tolerance is, and how you plan to execute security on your assets.


Step outside of information security for a minute. What do you think when you hear "compliance"? Labor laws? Taxes or zoning? Contractual obligations? Compliance management isn’t new to an entrepreneur. You already navigate a vast network of laws, regulations, and contracts. If you want to conduct business, you not only have to comply with their applicable provisions, but have to be able to document that compliance.

"Compliance" in the information security context isn't too different. Information security compliance means you can document how your company fulfills the security requirements of an external party.

The external requirements can be contract provisions with a vendor or customer or a published security standard. A security standard specifies the criteria, expectations, and guidelines that define minimum requirements needed to satisfy it.

Governments can impose security standards as a condition for doing business. Two examples:

Industry organizations can also impose security standard compliance as a condition. Any company that wants to process credit card payments must comply with the Payment Card Industry Data Security Standard (PCI DSS).

Governments and industry organizations also publish security standards that aren't required. A couple of examples:

Standards facilitate business growth by providing a common framework that helps independent organizations trust each other, encouraging voluntary compliance.

Voluntary or compelled, compliance with a given security standard is evidence that an organization has the processes and controls in place that meet the level of security specified.


The defining difference between a security program and security compliance is that a security program is internally driven while security compliance is externally driven. Here’s what this looks like when we break down how each functions within the organization: 

Scope and priorities of a security program are determined through internal assessment of vulnerabilities, assets, business needs, and risk tolerance.Meeting the expectations and requirements determined by a third-party, whether government, industry organization, or potential customer, vendor, or partner.
Continually re-assessed and updated to address evolving security challenges and business priorities.Reactive to changes made either in the standard itself or in an auditor’s or certifier’s evaluation of the organization’s compliance level.
Constant evaluation as to whether controls are, in fact, providing the expected level of security.Certification and audits determine whether processes and controls are in place, without addressing efficacy.
Represents a holistic, comprehensive approach to organizational security that reflects understanding that the business is solely responsible for ensuring its information and operations are protected.Provides a baseline of security measures required to gain external confidence in and approval of the organization’s security posture.

While they are distinct from each other, they aren’t an either/or proposition. They both have their role. Companies must have a security program. As noted above, in some cases complying with a certain security standard is required to do business. Where compliance isn’t mandated, working towards compliance with a relevant security standard is still a solid practice for two key reasons:

With a smart approach of mapping your growing security program to relevant security standards, the security program and security compliance complement each other. Your company’s security has to be internally driven; only you can make the crucial security decisions. However, complying with an external, industry-approved security standard is useful to build internal confidence in your security program and earn trust from other companies.

Creating a Security Culture

Protecting your company requires a robust security program with documented policies and processes; but without consistent, thorough execution of those policies, your company isn’t actually any more secure. Program documentation, no matter how detailed or organized, doesn’t harden any targets on its own. That's why building a company culture of security is a vital part of your security program. Lack of an active security culture throughout your organization undermines its security readiness.


Security for many small businesses and start-ups may be lax because they have no program at all. Getting started building a security program is step one, but the focus can't be only on securing devices and assets. Humans remain the weakest link in cyber defense yet often receive the least attention in most security programs.

When a documented IT security policy fails, you'll often find a human element behind it. Perhaps someone was careless with a company laptop. Did an employee fall for a phishing scam? Maybe even an IT team member forgot to deactivate the credentials of a separated employee.

Acknowledging the human risk to company security isn't about blaming any individual. Instead, it's about highlighting the failure of leadership to create and reinforce a security culture that prepares its people to manage security issues. A security culture sets up an understanding of risks, norms, and expectations of behavior, reinforcing itself through action. It provides employees with knowledge and the tools to make smart security decisions in compliance with the organization's security program. And ultimately, a security culture makes critical actions and behaviors second nature to everyone in the business.

The fundamental obstacle to creating a security culture? It’s the failure to invest the resources necessary to build up security-savvy employees who understand where the risks are and make security hygiene a part of their daily responsibilities.


There are five key aspects to creating a security culture. Each has its own set of challenges, but each is necessary to create a genuine culture that becomes embedded within the organization.


Security culture must permeate an organization from top to bottom. It can't take root if employees don't see executive leaders and middle managers taking security seriously.

Senior leadership must create and support a security program with clear lines of responsibility for executing the program. It requires investing in the resources needed to educate and communicate security policies, risks, and resources to employees. It also requires setting up systems that measure compliance and encourage security behaviors.

Last, leadership must personally demonstrate the security behaviors they want to see in others. If direct managers or senior executive teams are lax, it undermines efforts to create a genuine security culture.


Limiting your efforts to passive awareness campaigns won't create a security culture. A training video for new employees who answer some questions at the end? Anyone can pass a 10-question quiz on the material they've just seen. Making security policy documentation available online? Nobody's going to read through IT security documentation even if they do sign an attestation. When was the last time you read the Terms of Service before clicking “accept”?

Employees should regularly receive security communications that educate them about

All security communications should be written in “plain English,” free from IT jargon. They should also explain risks, and potential threats in contexts employees recognize.

One challenge to creating security-minded employees is that the threat and its consequences can feel too remote. Instead of talking about abstractions like vectors and endpoints, a security communication could convey real-world scenarios. It might show how bad actors can easily trick people into sharing sensitive information, which they can then use to gain access to the company network. Design scenarios that clearly illustrate the difference between a poor security choice and a strong one, making it easy for employees to understand what's expected of them.

Don't limit yourself only to written security communications. For example, we built a series of short podcasts on security culture for IT teams. At less than five minutes each, it's content anyone can consume quickly.

Short videos, podcasts, recorded messages, and even memes can all deliver security education in ways that achieve higher engagement and retention than a written email or policy memo. When you have a library of multimedia security communications, it's easy to share a constant stream of easily digestible security awareness material.


Ongoing security training is the more formal, interactive side of communication that helps build a security culture. Some training can be self-directed through security communication materials, but it doesn't replace regular live training.

We always recommend that organizations role play a security incident to test their response plan. Employee role plays are great training opportunities without having to simulate a full-scale event, and they also focus on building confidence in employee decision-making. Role plays cover how to identify a potential security risk and how team members should respond. Using an active role play training approach sparks the "muscle memory" that helps employees recognize shades of the scenario in real life.


Cybersecurity risks can be costly and need to be taken seriously. But creating a culture of fear or blame around security isn't going to yield positive results. Similarly, teasing employees with the promise of bogus bonuses to teach them the risks of phishing doesn't create an open, positive security culture.

A negative security culture leaves employees afraid to speak up. If they make a security mistake or see something suspicious, they may feel the personal risk of raising the issue is greater than the cyber risk to the organization. Employees using an unauthorized device or application for work won't let anyone know—they'll just continue to use it. All these behaviors open vulnerabilities that your security team may never see until it's too late.

Instead, create programs that reward and recognize employees for being attentive to security. One of the benefits of creating a digital library of your security communications is that you can measure which team members engage with the content and how often. These metrics allow you to reward and recognize people for


Teach employees to think of workplace cybersecurity the same way they do about workplace safety. The workplace safety framework is a valuable model for embedding security into all areas of the company:

One of the biggest challenges here is bridging the gap between IT staff and other employees. An IT team that uses too much jargon or shows impatience with non-tech savvy employees makes it harder to bridge that gap.

If you're a small or new company without an IT department, your challenge is tasking people who can take on the role of security advisor or act as the conduit to outside resources.

The point is that each employee needs to understand that performing their duties in compliance with company security policy is their responsibility.


Security culture is the component of your security program that can maximize compliance. A positive security culture yields employees who are mindful of their role in maintaining company security and confident in their ability to mitigate risk. The combination of acting on your security policies and security culture will position your company to take on bigger, more lucrative clients who expect you to have a comprehensive security program