The Truth About Audits

This post talks about the good, bad and ugly that we see around cybersecurity audits. It is informed by 4 years working for a company deeply embedded with PCI Compliance, and then about 8-10 years of experience helping dozens of companies with SOC 2, ISO 27001, NIST 800-171A and other similar audits.

The TL;DR is that audits can be helpful for improving an organization's security posture. On the other hand, an audit doesn't prove security and the more you game the audit the less likely it is that the audit improves your security. Furthermore, unfortunately, most audits we have seen are inconsistent across auditing firms and don't mean what you might think they mean.

The Good

Audits force an organization to do some introspection. If you identify appropriate "controls" to check, then the audit activity can help you to make sure you are doing the right things.

For example, if you say you have endpoint protection in place then the auditor may ask for proof. While producing the proof, you may realize that Mac and Linux devices were not actually covered by the tool you had in mind. That might lead you to use a solution that works with those devices, reducing your actual risk materially.

In some cases, the audit introduce controls you didn't know you needed to have in place! This can be extremely helpful for organizations that haven't oriented to a standard (see: why we use NIST 800-53 or which security standard should I use? for more information) and may not have identified broad sets of controls they want to have in place.

Sometimes an audit just tells you what you need to know, but from an outside party. Well, if the respected expert XYZ firm says we need to do it, then we can justify the expense to upper management. This just happens sometimes.

So in some ways, audits can really help organizations improve their security.

The Bad

For every customer we have that has had good experiences with audits, we have at least one that has had bad experiences with audits. That's < 50% positive feedback.

One huge problem is defining the audit Scope. I've seen audits where the auditors review all of the internal corporate IT as if internet facing applications didn't exist and sign off on an audit because the correct controls were in place for internal email and file sharing.

I've seen firms scope an audit a certain way and then come in and bleed customers after an initial audit agreement based on their lack of alignment to the controls.

I've also seen the opposite, audit firms that come in and charge a very low fee and basically check nothing.

Another problem with audits is that most of them aren't pass / fail and nobody reads audit reports. This means that so long as you can produce an audit report (eg. SOC 2), you can usually win business, even if the report says you didn't cover the main application the reviewer cares about or even if you had significant findings. Only very invested companies with strong teams are able to do this justice - and even then, they are subject to the whims of the auditor.

The Ugly

We have worked with a number of audit firms. You might be surprised at how inconsistent the process is. Some firms are quite technical and understand what controls fit in a given environment. Other firms have a list of controls and they are going to stick to them no matter what. Maybe the worst thing is that we've even seen significant variation in experience with different teams from the same firm!

Did you ever stop and think about how some of the most famous hacks were conducted against organizations that had been audited? Consider Target and PCI. Consider almost any recent hacking incident and SOC 2 Type 2. Was Heroku SOC 2 audited? GitHub? Okta?

It reminds me a bit of when I worked for a security company that helped build the PCI Compliance standard. I invite you to think for a moment about how good a business it is to define the standard for compliance, get the card brands to agree to your standard, then define the certification process for assessors, then be the main company that gates compliance to that standard! Can you say boondoggle!? But even PCI was at least a little bit prescriptive.

There is also a growing industry of tools to accelerate compliance. They typically integrate with a bunch of data sources and consolidate information. Whenever I see this, and the idea of automating compliance, I have to say - I do not think that works the way you think it works.

I do not think that means what you think it means.
Security and Compliance

For example, you may have a tool that claims to confirm that you are using a password manager. Great. Does it know which passwords are in scope and that those passwords are stored ONLY in the password manager? Can it tell if you are actively using the password manager?

Let's take another example, suppose a tool tells you your AWS environment is SOC 2 compliant. What does that even mean? Does the tool understand anything about what your dataflows, user lists, and other details are? Do they think they can confirm ALL of your security settings are applied properly AUTOMATICALLY? Consider the question of who has access to what data? I've basically never seen a tool in any security domain that can effectively automate that.

So this whole idea that we can automate compliance is either jaw droppingly naive to me or reflects on the inadequacy of the audits - OR BOTH! And by the way, we build security tools that are directly adjacent to (but different from) both audit compliance ( and AWS Compliance ( One thing I will say, I'm all for using API's and open tools like that let you get the data you need for compliance. I will just insist that you have to be able to ask and answer questions and not just run a tool. Some auditors we work with won't accept CLI output as evidence, they need to see the AWS console. How do we reconcile that with a fully automated acceleration tool that is checking a bunch of things that may or may not matter?

So the idea that any audit (and particularly SOC 2) consistently demonstrates security is so obviously far from the truth that I can't believe that "the community" is using it as a standardized baseline these days.

The worst thing is, I don't believe it is ignorance so much as avarice on the part of the auditing community that we see this. Certainly many in the security community know that these audits are fundamentally flawed.


We work with some audit firms that we respect and like a lot. We believe they help our customers improve and hold themselves accountable for their internal security.

We also work with firms and tools that we think don't add a lot of value - let alone security - and which make a lot of work for the organization.

We recommend that you go into these relationships with eyes wide open about what you are trying to get and what your audit actually means based on the price and type of auditor that you have.

That being said, maybe it is time for a new audit standard. Maybe it is time for a better security standard. In either case, we believe collaboration and people will be a foundational part of it.

Phishing Job Candidates

A job candidate received a solicitous phishing email from what looked like a valid client domain but it turned out it was not the client. The call was not coming from inside the house ...

We recently came across a phishing campaign at a client that caught our attention because it was highly targeted to a company (our client) but the targets weren't the typical "internal employees". Rather the targets were outside people that had reason to interact with the company - in this case job candidates and even potential candidates. This introduces some interesting wrinkles into the usual approaches for defending against phishing and protecting organizational reputation, so we thought it would be worth highlighting some of the details of the campaign and what we did.

Phishing is where someone, typically some sort of organized cybercrime gang, sends a malicious email to a group of people hoping that someone will respond, click a link, open an attachment or something like that. The objective is typically to compromise credentials or the user's computer, or potentially to collect secret information (eg. account info) to perpetrate fraud. We have written previously about spearphishing.

What It Looked Like

In this case, the phishers did the following:

From the candidates perspective, the emails looked somewhat realistic.

Dumb Luck Detection

With most phishing campaigns, you see lots of evidence of them. Employees report that they got a weird email. Or maybe you even get the weird email yourself. At our more advanced customers, we have ways of sharing information about new campaigns we see - eg. sharing screenshots of examples in a #security channel.

With campaigns that target potential job candidates, the candidates don't have this avenue for discussing things with the company. Unless a candidate just smells something phishy and decides to tell you about it, how would you find out about it? You certainly can't train the planet to prevent people from falling for phishing related to your organization.

In this case, the only reason the campaign was detected at all was that one of the real candidates (again not an employee!) was also targeted by the phishing campaign and called the two different interview processes out to the recruiter from the actual company.

What Can We Do?

One of the keys to the success of this campaign (well, relative success, we're not aware of anyone actually falling for it yet - but people engaged with it) is that the domain looks credible. To prevent this, it can be helpful to register similar domains, like those with:

Once the domain was registered, a second thing we did was report abuse and ask the DNS provider to disable it. It is unclear how effective or quickly this will be done. (It has not been taken down yet)

Another thing we recommended, but which is very hard for companies to do (and this one didn't), is to publish a blog and social post with the detail of the campaign so that potential targets can find information to defuse the emails they are getting on your website.

It should be noted that there are any number of workflows where phishing like this could be done, not just job search. Vendors, partners, customer engagement, etc. There was a short period of time where we were concerned that there was leakage of candidate information through one of the many third party systems hosting the process. After further review, we don't think that was the case, but it still may be something an organization would want to do proactively to prevent these attacks from being more credible than they otherwise would be.

Finally, it is always a good idea to think through your operational processes and communicate about those early and often with people that are interacting with you. So specifically, you can:


A critical step in this scenario was the recruiter listening to the candidate's input and believing them that something was not right. It turns out that being human and communicating has big benefits.

The follow ups are also important. IT looking at the detail to identify the phishing domains, reporting them, and capturing the detail so that the company knew what the patterns were was important. This allowed them to communicate with candidates and update the information in their posting and their more general communication strategy.

Of course, we can't stop an attack like this from happening, and we can't really be responsible for every misuse of our identity - but being proactive and trying to make it easier for candidates not to get fooled by phishers is worth the effort. If you are a company wondering what to do, you could start by adding this as a risk in your Risk Register.

To me, that is is what is scary about this scenario: there is no obvious way to stop it and there is no real limit to what or who could be targeted. So like with many things in security, we have to live in the grey.

Feature Spotlight: Network Scanning

As part of we offer network vulnerability scanning. Most standards (eg. PCI) require that you do at least quarterly vulnerability scanning. Vulnerability scanning is important for identifying resources on your networks and figuring out that they may have holes that an attacker could exploit.

Vulnerability scanning is a pretty basic activity that every organization with any internet facing systems should have in place. That is why we include it in SPIO. Otherwise, clients have to go find a scanning vendor and spend who knows how much extra time and money getting it in place.

What Makes A Great Scanner?

Our founder, Matt Konda, spent 4 years building a PCI ASV certified vulnerability scanner. Excellent scanning products on the market are differentiated by effective signature mechanisms, sophisticated reports, false positive management, integrated endpoint agents/management and low time to signature for newly released CVE's.

The more you integrate vulnerability management, the more sophisticated the workflows and management features are. Some scanners do more checks and fuzzing around web applications versus just network level checks. So in some cases, having a great scanner is worth it.

The problem is, in most all cases, the scanning is pretty dumb. It is just checking for open ports on a host, reading the banner and using something like a regular expression (regex) to extract a version number and then comparing it to a database of known vulnerabilities. In other words, at its core, the technology isn't that sophisticated.

SPIO Scanning Features

The features we include around scanning are focused around the core nuts and bolts of the offering. To make the offering robust and as up to date as possible, we leverage a widely used open source vulnerability scanning tool. As it turns out, this can be tricky to set up and optimize - so our customers find it nice that they don't have to worry about it.

As an SPIO user, you can manage your environments (what should be scanned) in the application. You can then view recent reports, which are provided in PDF and csv format for easier handling. We keep track of past reports so that you can always show that you've done your quarterly scanning duties.

Maybe one of the most important related features is that our team will help you identify which issues are real and need to be addressed. Vulnerability scanners are notorious for creating a lot of false positive findings. Sifting the real issues from the mass of common findings takes experience in the form of a trained eye. What this looks like to our customers is that we set up the initial environments (we can even help you do DNS discovery and the like to identify scan targets) then each quarter clients get items escalated that require attention.

Let Us Assist You!

In the Assisted Tier of SPIO, our team helps you understand the scan results! This ensures that your team is able to understand and effectively fix the real issues. It also means you don't waste your time on false positives!

We tried to make our vuln scanning as simple and pragmatic as possible. Whether you have us help you, or you do it yourself, the tools are right there for you in

Feature Spotlight: Vendor Tracking

Many of our customers find us because they are being subjected to a larger company's vendor management process and they don't really know what to do.

One of our major goals as a company is to systematically help small cool innovative companies develop security maturity so that they can compete and win with bigger companies.

An important part of developing security maturity is managing your own vendors and the potential risks they introduce. In this post we'll talk about vendor risk, common processes for dealing with it and how we handle it in our tool.

Did you know that with SPIO Assisted, we can do vendor tracking for you?

Vendor Risk

Does anyone remember the Target breach disclosed in 2013? It stands out has being a very large breach (40M credit cards) but also for having been one of the first highly publicized breaches where the entry point turned out to be a third party HVAC vendor. This may have been the moment in time where attention started to more deeply focus on third parties.

The problem, of course, is that you can build a great system and do all the right things for security in your system and your code - but if you integrate with or build upon something that isn't secure, in many common cases, you inherit their weaknesses. People don't want to buy things that they could easily know are weak.

This has gone beyond being a Good Idea™ and become something more like a mandatory minimum bar for doing business with most bigger companies.

We have seen all kinds of risky vendors:

The Process of Vendor Tracking

The first step in dealing with vendors is to figure out who your vendors are and how you should track them. We often ask finance for a list of vendors. Then we try to get pulled into procurement processes so that we'll know that a vendor is being vetted and onboarded by the accounting team.

You wouldn't believe how common it is that organizations use vendors without realizing it. Maybe someone in engineering set up a "free" account. Maybe someone in IT paid for a backup service with their company credit card. Getting a handle on who your vendors even are can be trickier than you might think.

Once you know who your vendors are, you need to think about what you need to know about them. Do they handle your most sensitive data? Do they handle it carefully? Do you need an audit to confirm that they do?

The diagram below illustrates an example flow chart you could build for your vendor management program.

Vendor Management Flow

Tracking Vendors

One way to help make sure you are doing the right diligence on vendors is to use an application to help structure the process. That's why we build a vendor management module into

SPIO Add Vendor

The Vendor Tracker makes it easy to:

Vendor Questionnaire

In the big scheme of things, Vendor Tracking is a pragmatic and minimal feature in SPIO. There are platforms you can buy that make it easy to administer very complex vendor management programs. We are not trying to compete with those, but to give smaller companies the basics that they need.

Let Us Assist You!

In the Assisted Tier of SPIO, our team helps you with vendor management. This ensures that your process is consistent and effective. It also makes it faster because many of our clients use the same vendors, so we don't necessarily have to do a full deep dive on diligence for every one of them.

For this to be effective, we still need to get plugged into your procurement process so that we know that a vendor is being onboarded, or renewed. But once we know that, and how they are being used, we can do most of the evaluation on our own. This can be a major time saver for our customers.

We tried to make vendor tracking as simple and pragmatic as possible. Whether you have us help you, or you do it yourself, the tools are right there for you.

Feature Spotlight: Risk Register

On some level, the whole point of a security program is to manage risk. In (SPIO) we provide policy around how the risk program should work and some templates for a risk management process that you can adopt as an organization.

On some level, the foundation of that is a willingness to document and talk about risks. The risk register helps you to do that. In theory, the idea is that anyone can report a risk that will get put in the risk register. In practice, it is often the technical team, security team or even users that report risks.

Once a risk has been reported, we track it in the register to help us document that we are aware of it and that we handled it. Often we use the risk register as part of our frequent discussion with broader management to make them aware of risks that we see and how we're dealing with them.

The Register Itself

In SPIO, the risk register makes it easy to create and track risks. Then you can see who the owner is, start to estimate probability and impact and track the status, which is one of:

SPIO Risk Register

Risks in SPIO also have fields to gather:

Of course, it is helpful to understand when risks are identified and when they get handled.

It is a bad sign if risks are commonly identified but then there are long periods before they get handled.

It is probably a bad sign if there are no risks identified. That suggests that the organization doesn't have a very effective way to realistically identify and deal with risks.

If you are struggling to think about risks, a threat modeling exercise could be helpful. You can use our tool here to help with that:

In the Assisted SPIO tier, our team will help to manage the Risk Register and identify and track risks. We also conduct an annual deeper Risk Assessment where we look to make sure the overall program is aligned to your overall risk.

Ultimately, the Risk Register is just an easy way to center an organizational discussion around risk and track outcomes.

Automated Mass Spearsmishing

Phishing is where someone, typically some sort of organized cybercrime gang, sends a malicious email to a large group of people hoping that someone will respond, click a link, open an attachment or something like that. The objective is typically to compromise credentials or the user's computer.

Spearphishing is where such a campaign is conducted in a more targeted way, typically focusing on specific people with more personalized context that would make the campaign more compelling. Whaling is where spearphishing targets executives (think whale == big fish)! A common spearphishing or whaling objective is to get a financial officer or accounting team member to transfer money or change account details so that payments get misrouted.

What we have been seeing lately are campaigns that are conducted at a larger scale that is likely highly automated, but that also have the context required to be compelling and a request that is possible for many tiers of employees (not just finance execs) to do. We also got targeted directly by one of these, so we can share the detail. Let's do it!

The SMiShing

Smishing is where someone is doing phishing (communications with malicious intent) over SMS or text messages. Our particular text looked like this:


In this case, there are a couple of obvious things to note about the Smish.

  1. It is addressed to Keely and obviously sent to her phone.
  2. It claims to be from Matt Konda, who is the CEO of the company Keely works for.
  3. It is from a phone number that is co-located to Matt Konda's typical location. (Texas)

Now in this case, we're lucky, Keely is on the ball and immediately realized that this wasn't real. It might have been the:

I'm excellent with texts ...

Phisher #1

There are some obvious other tells that we should call out:

  1. It was from a new number that is not where Matt typically communicates from.
  2. It is an unusual communication channel for something important.
  3. The urgency but also unavailability to confirm on a call or via a normal channel is to be noted.

Keely didn't respond, so we can't say for sure what would have happened next. However, we have seen this play out with customers with the exact same text (the "I'm excellent with texts" is hard to miss!) but from the customer CEO to an employee. When the employee responded, the campaign asked the employee to purchase Google Play gift cards.

Note that we have also seen other SMS campaigns and even more classic social engineering campaigns (phishing) to get people's phone number that were later used in an SMS campaign like this.


Based on what we are seeing, either this gang is particularly motivated and have time on their hands to do their research, or there are various layers of automation involved.

My guess is that they are using data from a LinkedIn data breach to associate people to companies, grab the company names, the people names, the phone numbers and emails and be able to formulate a programmatic automated but still targeted (contextual) campaign.

A particular interesting characteristic is using the CEO as protagonist in texts. It is common to see this used when an account has been hijacked to do the same thing, but maybe because not everyone has the CEO's real cell phone number it isn't always obvious that it isn't coming from them? SMS doesn't have the context (eg. signature, logo, etc.) that email does. Then again, with the data from LinkedIn (or whatever it is) the attacker could probably make a fake signature that looks pretty realistic substituting title, role, company, logo, etc.

Note that we have also seen other SMS campaigns that are similar in the sense that they use the CEO role but different types of messages - sometimes even targeting NEW employees.

Of course there are also the standby classic social engineering campaigns (phishing) to get people's phone number that were later used in an SMS campaign like this.


Educating employees about social engineering like phishing and smishing is a key part of a security program and can be one of the most important things you can do. We want employees:

SPIO can help provide this training. One of the customers that was targeted said that it was our training that made them stop and not follow through.

... your training was spot on in triggering all of the necessary awareness for me to start varying this exchange


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.

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.

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

Your First Security Hire

We often talk with companies that are thinking about hiring an FTE to help them with security. This post covers some of our thoughts and experiences in this area. As with many areas of security, there is no one size fits all approach that works here, but there are some pitfalls and ways to make it work more smoothly. Here’s the TLDR; use a tool like to do the program part and hire someone that does DevOps.


It is common that organizations realize they need help with security when they find themselves spending a lot of time on 3rd party questionnaires or they need to meet some sort of client requirement around security. It’s easy to justify when a CTO starts spending 10-25% of their time (or more) on security! A lost deal is an easy trigger for more security as well.


Often the first thing a company thinks is that they want to hire someone to do the security for them. This is totally natural. A challenge we have seen with this approach is that it isn’t clear whether to look for someone senior that is a leader or someone that is technical.

The leader might be able to answer the customer questions, and help with some directional decisions. But they are unlikely to also be able to roll up their sleeves and do the work to secure the organization when it comes to end points, cloud infrastructure, etc. Hiring a leader makes sense if you also plan to make a significant budget available for tools and hands on hires. It could make sense if you are in a regulated area, and you are pretty sure you found the right leader. Most great security leaders aren’t looking for a position where they are the only person though, so you have to know that this may be the exception more than the rule if you think you found it.

A hands-on person has the benefit that they can go do security work right now. Maybe you want them to help manage IT endpoints or work in a security monitoring or engineering role. You might want them to also answer questionnaires and deal with customer requests. But be careful. Often the folks that fix things are not the same folks you want talking to customers. Very often, this type of hands-on role needs to work very closely with existing IT resources and in fact the responsibilities are not always clearly segregated.

It is surprisingly common for relatively junior security folks to be strong-minded in new leadership roles. Meaning they may feel the weight of responsibility and struggle to communicate in a constructive and productive way. They get frustrated when organizations can’t just do X,Y or Z to address an issue. It turns out that communication across the organization is a key success factor for people in security roles. So is long-term planning.

Another pitfall is looking for experience with a very specific tool instead of general technical breadth and capability. Exposure to a single security tool suggests that a candidate may be knowledgeable in an area but may not understand the big picture. I can’t tell you how many times we see security tools purchased but not used effectively. This often happens when someone likes a tool or vendor and brings them in but maybe it doesn’t fit or isn’t a priority organization wide. An increasing number of your tools should be cloud based and easier than ever to integrate. You may not want a specialist…


Sometimes these growing pains are inevitable and reflect that an organization has put off security just long enough to give itself an opportunity to be viable from a business perspective. Other times these growing pains are a sign that it is too late and security is about to catch up with you.

Whether it is developing processes, evaluating vendors or architecting the moving parts in your cloud environment - all of these things are easier to do sooner than later. You won’t know when the growing pains are coming and whether you’re on the “good” size or “bad” side of them until you actually fail.

One thing we can say, is if you ease in and start now you can be making important progress that will be valuable later. Just start now in a small or “reasonably sized” way!


Whoever you bring in to help with security is going to have to deal with difficult situations. Here are some examples:


OK, in full transparency: we built a tool to help you outsource the program, but we did that because we believe this so strongly. If you can get close to what you need with out of the box policies, process templates, training materials, and core tooling and task management, why would you hire the security person?

If you can get an experienced person to help when you need and appropriate support running your vendor management, risk and audit programs, why would you hire a junior or unproven resource for that?

The costs are also much lower than even a junior FTE.


When you’re ready to hire and you’ve considered the program platform, think about where the highest impact will be.

We’re opinionated; and we lean toward well rounded doers in general, not just for your first security hire.

You might consider hiring someone who can help with DevOps automation. Coding skills are important for automation. They also suggest adaptability to different tools. You want to be able to use appropriate tooling and apply it with success. If they can use Terraform to help fix things in your cloud environment, that might be a very helpful thing. They become enablers instead of gates.

A good thing to do is to write down how you think the person is going to spend their time. We also like to do fictional one year in the future annual reviews to communicate what the expectations and areas for growth are.

Whoever you hire, communication, flexibility, planning, organization, an ability to talk about risk and some technical skills should be part of your calculus.