Clear Security Hurdles and Win Deals

Are you a CTO or someone on the IT or Engineering team at a smaller tech company who gets pulled into sales processes to answer security questions? You probably just want to focus on building your product or hiring your next engineer, but here it is ... a security questionnaire ... and it is always an emergency, right!?

Or maybe you are a CEO or VP Sales at a company that has to ask the tech team for help...

This post talks about how to navigate these situations. Click below for a quick guide for preparing your security to pass these hurdles.


One of the most common reasons companies ask us to help them is that their prospects are putting up lots of hurdles in their sales process. Nobody likes to have to stop talking about their value proposition to explain their security posture. Especially when it isn't a great story.

The first thing you have to understand is that it is totally normal to consider security in a vendor management process. In fact, it is a good thing! Not only that, most of these companies have already committed to doing that - so they aren't singling you out, they're just doing what they do. It turns out every vendor like you represents risk, and they are all trying to mitigate risk.


One thing that can help a lot is to build a close and transparent working relationship with a stakeholder who can help you to identify and overcome specific blockers. Sometimes companies have hard rules about certain things. For example, they may say that you MUST have a list of subprocessors.

Your stakeholder can help you understand that and direct you to the areas you must address versus a laundry list of nice to have security items.

Sometimes a stakeholder can help you bypass security altogether. We don't recommend that in general, because when the customer's security team finds out and evaluates you they may hold you to a very hard and fast standard.

Usually in these kinds of deals, the stakeholder can ask internal questions to help get context and understand how important the different things are. We recommend leveraging that and building a good relationship so that you can navigate this cleanly.


There is a saying that "in crisis there is opportunity". Although one security review really isn't a crisis, even if you lose the deal, it is true that there is an opportunity to change the whole dynamic around the security discussion. If you spend a small slice of energy on an ongoing basis, you can build to the point where you have solid answers and these types of security hurdles are easy to jump. You become like a pro athlete that can do them without breaking a sweat.

Even better, you can start to differentiate from your competitors who aren't taking security very seriously and don't have a good security posture. We work the other side of this issue too, helping our clients evaluate the security of their vendors and sometimes we guide them to explore alternative vendors that may have a more reasonable security posture. We're pragmatic about this. It only really matters when very sensitive data is being shared with the vendor and so on. But it is absolutely true that security factors into vendor selection processes and you can stand out by doing a good job.


As with everything in nature, there is a balance. You can do too much for security. You can do too little for security. Only the people at the company that know the cost of security, the cost of losing business, and the potential increase in revenue of investing in security and creating a strong story can really understand all of the trade offs.

Sometimes people do lose deals because they don't have strong enough security. In our experience, this is extremely rare if they bother to open a dialog with the prospect and make reasonable commitments. But in some cases, a company has a hard line that every vendor must have a particular audit for example. If the audit costs $100,000 to get, it may or may not be worth doing it.

At some point, security is a business decision.


What drives us at Jemurai is helping our customers succeed. We get excited watching our customers close deals, land funding rounds, sail through M&A or pass audits. Doing hurdles doesn't have to be a slog when you keep the end goal in mind.

We built our tool to help people build their security programs, so of course we think that is a great option, but you can also check out our consolidated guide and get started doing it yourself!

Discovering A Competitor's Internal Data Online!

Imagine that you stumble across a large amount of data on the internet and realize that it includes a treasure trove of internal pricing and partner information from a direct competitor of yours. The data gives you all kinds of clues into their business, profitability and partner agreements. What would you do with it?

This post talks about a real world scenario where this happened and how it was surprisingly complex to handle. We also talk about ways to make sure it doesn't happen to you.

Accidental Data Discovery

I'm not exactly sure who found the data or when. It might have been an industrious salesperson. It might have been an accidental Google search result or even something mentioned in a Reddit thread. I don't really think it was malicious or targeted. But by the time we got involved, it was clear that there was a public S3 bucket containing substantial amounts of data for a customer's competitor.

To make it easier to tell the story, let's call:

So anyway, when we joined the discussion the AcmeRiverCorp Team was already going through the BurningCorp data and it almost resembled sharks that smelled blood in the water. They hadn't gotten that far though and the number of people in the loop were very few. They clearly knew there was something wrong and reached out for our advice. We quickly advised the AcmeRiverCorp team to take a step back and pause these search and collect activities. We made sure people stopped spreading the word and tried to understand what had really happened.

Then we had to figure out what to do about it.

What Would You Do?

There are a lot of different ways this could have played out.

It is, of course, possible that AcmeRiverCorp could have copied a bunch of publicly available data and made full use of it to target BurningCorp. Trust me, I've been deep enough in business to have seen these kinds of lines crossed in the past. As a side note, I once played whistleblower and the VP that handled it tried to tell me:

This isn't an economics class, this is business.

Anonymous VP

To which I replied:

I think you mean ethics class not economics class...


The point is: many people at many companies would have taken all that they could, used it any way they wanted and never thought twice about it. Not only that, some people and companies actively look for this type of data and exploit it. Sometimes I wonder what it would look like to be a competitive data bounty hunter ...

Anyway, when we found ourselves here, we believed that there was a substantial risk (never mind the ethical side of it) that if anyone at BurningCorp got wind of the data being used, they would be able to go back and identify that it had been accessed by AcmeRiverCorp's employees. Even though the data was publicly accessible, you never know how laws will be interpreted and AcmeRiverCorp might even be held legally responsible for damages to BurningCorp based on a loss of business tied to the exposure of the data!

So we quickly convinced AcmeRiverCorp that they should not use this data to their advantage and they should stop accessing it immediately. Turns out the golden rule applies and some people still honor it. It is a credit to AcmeRiverCorp that they listened at this time and immediately stopped accessing the data. It was basically leadership with a true North that were able to set the tone and manage this situation.

But then we thought about how we could let BurningCorp know that their data was flying in the wind and that raised the next problem. If we tell them they have a problem, they may immediately suspect us of nefarious purposes. If they look at logs, they can still see that some AcmeRiverCorp employees may have accessed the data. It wouldn't be easy, but it was a risk we weren't sure we could take.

In the end, we played the independent security researcher card and reported the issue as though we were an independent bounty hunter so that BurningCorp could respond and take action, but wouldn't be immediately litigious against AcmeRiverCorp. That seemed to have worked out. But even that wasn't without risk.

Clearly, the best case scenario would have been to not expose the data at all in the first place.

Attack Surface Analogies and Tools

Part of what we're talking about is knowing your attack surface. What data do you have exposed? How could someone target you? It is related to threat modeling but not the same thing. It is related to risk but is a more focused lens for it. A nice part about the concept of an attack surface is that it often maps to concrete technical things in your environment. When we talk with people about their attack surface, it is usually a pretty solid and direct conversation because either it is there or it isn't - and the most common outcome is that the technical team learn about mistakes that have been made and just fix them.

A common analogy for talking about attack surfaces is a house. Does it have a good roof? Are the doors and windows closed and locked? Could someone easily get in? Who has keys? Is the garage code published online? Like most online companies, there have to be functional doors for the house (or company) to function. How are we staying aware of those and making sure we know about them? Taking the analogy one step further, just by doing a review of the exterior we can often clean things up to make the house seem more secure from the outside.

Mapping online systems and capabilities to an almost physical situational awareness is useful, but it is a pretty exhaustive exercise to do in your head and based on theoretical information. Thankfully, there are a lot of useful open tools we can use to help us. Some of the ones we like are amass, dnstwist, nmap, openvas, fierce, dig and similar. We typically take the output of these and talk through it with clients to explain and prioritize any action items.

Of course, from a tools perspective, there are also a number of commercial tools that can help you do external resource enumeration and provide scoring and even risk measures. These may be things to consider as you grow. With SPIO clients, we prefer to have a conversation and blend in a bunch of open tools that combine data about domains, email, network and other configuration that is all easily and freely accessible about your company already.

If you are interested in a quick free attack surface evaluation you can request one here or just fill out this form inline:


There really is something to being a good corporate citizen and with data breaches, sometimes we get presented with challenges we never thought we would see. Approaching each situation ethically and with a sense of the greater good (and maybe getting advice!) ensures that you won't cross the wrong lines. I know once the dust settled, everyone felt better about how we had handled this situation.

From a more concrete action perspective, checking your own attack surface proactively can really help to reduce the risk of an event like this happening to you. You can work with us to do that if that is helpful.

Ultimately, building a security program is more than any one piece of this and the attack surface is just a small part of it. But it is an important part that can make a significant and important improvement fairly easily. If you want help thinking about security more broadly, we recommend our tool.

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: Policies

A foundation of a security program is a set of policies that establish a common understanding of organizational commitments around security. In, we provide template policies that align to NIST 800-53 and which we have then mapped to tasks - things you need to actually do to meet policy.

Of course, you can download any number of security policies from the internet and frankly, if you email us at we will point you to our templates for free. The truth is: writing the policies isn't the hard part of adopting security policies in a program. The hard part is actually making sure everybody knows about them and then following them!

Policies are important because they set expectations across an organization.

Policies and NIST Standards

We centered our default policies around NIST 800-53 because it allows us to build policies that are aligned to a broad set of industry standard controls. That makes it easier for us to map to things like NIST CSF and other standards which often also reference back to NIST 800-53 controls.

We wrote our policies so that most tech companies could basically adopt them "as is". We made them real, but pragmatic. Simple but complete. Our policies cover:

Policies in

Policy Features

The features we include around policies start with appropriate proven templates for each policy. That gets you started fast with templates that have been used by clients to pass security audits or demonstrate security during acquisitions or sales diligence. But we also provide an online editor, version control, the ability to upload your own policy (say in Word) and to track versions. This ensures that all policy changes are trackable.

We also provide a simple policy acknowledgement capability so that you can deploy and confirm policies are acknowledged by all of the employees that need to be aware of them. Since they sign on with SSO (supporting Google Workspace or Microsoft O365) it is seamless to invite them and let them acknowledge policies.

Let Us Assist You!

In the Assisted Tier of SPIO, our team helps you understand policies! This ensures that your team is able to understand and effectively leverage policy.

We tried to make our security policies 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

Planning for Escalated Hacking

Many of our customers have been asking us how they should plan for escalating hacking and cybercrime activity in light of the conflict in Eastern Europe. Whether it is Russia, cybercrime gangs or other nation states operating under the cloud cover of that conflict, increased hacking is certainly something we can reasonably expect.

The TL;DR response is: if you have a good security program in place now, there isn't anything you should necessarily be changing based on this situation. If however, you are not sure you have a solid program in place, there's probably no one thing you can do - so you'd want to put a broader plan in place and you should expect that may take some time.

I realize this probably isn't what anyone wants to hear, and I will still go ahead and list some important things you can do and key references to try to be as useful as possible, but we have to be independent thinkers and stay honest - and I'm not sure the hype is helpful.

Note, if you are interested in what to for your developers in the Ukraine, we wrote a post about that.

It's Too Little, Too Late

no easy button
Is it easy?

Ironically, many of the queries about escalations came from customers whose board members started asking about security because of the conflict. Unfortunately, when the bits are flying the reality is it is too late to start building a program and putting in place the defenses you need to resist escalated hacking conditions.

There is no "one thing" you can do to prevent it. There is no easy button.

It makes me wonder if the same board members were encouraging their teams to build out security programs in general. It also makes me wonder if the board members are also on the boards of the security companies they are promoting.

You can't buy a tool to eliminate your risks from cybersecurity conflict. You need to plan and execute over time to manage escalated security environments.

OK But Seriously, What Can We Do?

There are a couple of good resources I would point to on this. CISA provides information and great resources in this Shields Up page. The takeaways are largely what we would advocate as well:

Another thing you can do is look for software that you are running that CISA has identified as having been targeted by hacking campaigns: known exploited vulnerabilities. Of course, there are likely other vulnerabilities that aren't yet on that list, but this is a good starting point. Generally the action for any software you are using in this list is to disable it or to update it to a version that has a fix for the vulnerability.

In the big picture, we would normally advocate for a holistic program aligned to a major standard such as NIST 800-53 (which is what our application uses as its primary standard) and broadly speaking, that is what we feel you need to prevent issues from happening.

If this is too big, you could use our worksheet on the 21 Actions to Improve Security Today. The bottom line is there is no time like the present to make sure you are planning for escalated hacking - but you need to plan and navigate that yourself, not based on some checkbox solution.

The Elephant in the Room

The easiest way to get hacked is to leave an unpatched system online, or to have a user click on a phishing link and supply their credentials. But watering hole attacks where a themed site is set up with outrageous content to attract people and then distributes malware as they visit are also quite likely. Vigilance can help prevent or detect these types of attacks as things escalate.

On the other hand, a problem is that many large companies have deeper security problems you can't easily build a plan to mitigate. For instance, it is likely that all major companies (including say cloud providers) have sleeper intelligence agents working there as full time employees waiting for a direction to cause damage or wreak havoc. If things get very bad, disruption of major cloud services might become a strategic goal for a party that has the power to pull that off based on this latent threat. You can't prevent this with vigilance. You can have backup and alternative delivery strategies to maintain maximal business continuity, but until recently such an attack would seem so far fetched as to be not worth planning for.

Conclusion - Planning for Escalated Hacking

With each passing day I am more shocked and saddened by the events unfolding and I feel a sense that people are sensationalizing or trying to get as much out of them as they can. I'm unimpressed by the boards' new attention to cybersecurity. They should have been funding cybersecurity all this time.

The reality is, for most likely problems you should already have a solution in place. But for some, you don't and you can't. That is the reality. Security is a marathon not a sprint. The best way to plan for escalating hacking incidents is to start and maintain a broad security program.

Map credit: Ukraine - Wikipedia - By Rob984, ByStaJ - Location European nation states.svg, CC BY-SA 4.0, Link

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: Training

Security training has been a focus at Jemurai for all of our 10 years in action. It is central to our mission, which is enabling organizations to meet security more squarely on their terms. (See our Origin Story) We want you to know what you need to know and to be able to handle as much as you can yourself!!!

Historically, most training we do is highly technical, targeting developers. It could be around the OWASP Top 10 or security in AWS. A common offering is a monthly injection of relevant security training covering a recent issue like dependency confusion or the Log4J issue that happened at the end of 2021. We typically deliver via Zoom (these days) but we love doing live training and answering hard tech questions on the fly.

In building we realized there were broader organizational needs around training. In addition to deep technical training, organizations need training for everyone. They need to demonstrate that they have provided the training and that people have taken it. They may need more detailed training for particular people around privacy or a particular standard.

So we built out a training library as a cornerstone of our offering. Some features of our training:

Our training does not include:

The Training Categories

In SPIO, we have training in the following areas:

When you click on a training, you get a video viewer like the one below which allows us to track the progress through the training and collect the data needed to demonstrate that training has been sufficiently distributed.

Training Video in Action

We tried to make the training as short and pragmatic as possible. We tried to have personality and make it as fun as possible. Of course, it is security training so some people will enjoy it more than others. But the takeaway is that you can easily meet your goals and provide very good training content to your team with

Securing Tech Workers in Ukraine

Although most Jemurai and customers are based in the US, many customers have folks working all over the world including the Ukraine. Several customers have asked us what they should do to protect their people, information assets and otherwise prepare for potentially escalating conflict there.

Now, as a Ukrainian friend of mine was quick to point out, this is not as new a conflict as most people in the U.S. may think. So hopefully if you're in this situation, you've already identified the risk and given thought to how you think about securing your systems. And in many ways, it just raises the stakes on things you should probably already be doing as part of your security program. But we thought it made for a thought provoking exercise and decided to write up our thoughts in this blog post. Note that we are not intending to take a political position in this post, though I think we can generally say that we hope that armed conflict does not escalate - for everyone's good.

The Context

First, it is important to understand and level set on a couple of things that are true in the case of the Ukraine that are not necessarily always true:

  1. There is a history of both denial of service and deeper IT intrusions in Ukraine
  2. There is an active propaganda campaign that may be casting a wide net
  3. There is a risk of physical loss of assets
  4. The lines between government forces and civilian actors are blurry
  5. The same government and civilian actors have a history of attacking US based companies

Based on all of this context, there are some things that become more important for your organizations security - and the sections that follow cover these.

Note that even if you do not have team members in the Ukraine, it is probably also a good idea to note that CISA has been publishing information about active campaigns and the vulnerabilities that are being used in them. With general tension and adversarial behavior either increasing or being more visible, it is probably a good time to step back and think about your organization's security posture in general and make sure it is aligned to the risks out there.

CISA also provides further information and great resources in this Shields Up page.


These are the protections we identified as being very important given the context.

Business Continuity for Systems Hosted in Ukraine

Most of our customers that have a presence in the Ukraine have developers but not hosted data centers or offices with backend systems. However, if your organization has hosted data centers or offices with backend systems running, it is critical to identify these systems and make a plan for how you would run any of those backend services if the ones in Ukraine were unavailable.

We would start by making an inventory of these systems, ranking criticality and then figuring out what alternatives may be possible. This should be part of a typical business continuity or disaster recovery plan.

An additional consideration that will come up again is the possibility that the Ukraine hosted systems could be taken into possession.

Encrypt Hard Drives

Generally it is a good practice to encrypt all drives on laptops, phones, tablets, desktops and servers. This can be done with OS native software in most cases. The likelihood that a device might get lost, left behind or repossessed during a prolonged event is significant. Generally having a device encrypted is similar to a remote wipe capability - which might also be a good thing to establish so that a device can be wiped in the event it is lost.

Strong VPN

To protect against network traffic in general being rerouted and inspected, we recommend using a Virtual Private Network (VPN) for all users. It isn't 100% clear what the capabilities of various threat actors are but it is quite possible for network traffic to be rerouted during a conflict through either seizure of local network infrastructure or associated hacking exercises.

Using a VPN can protect basic traffic interception. You may also want to look at how access to production environments works and restrict it such that it has to be intermediated by an auditable command channel. For instance, using AWS Systems Manager Session Manager provides a strongly authenticated, auditable way to access your production environment. A related control is network segmentation which needs to be in place in any data center to help enforce things like least privilege and separation of duties.

Anti-malware (XDR)

In addition to the increased risk of physical loss of devices, there is a likelihood that there will be organized campaigns to win Ukraine based digital assets - including both phishing and website based malware campaigns (watering hole attacks). In other words, attackers might stand up websites with inflammatory information (from a variety of angles) and use the websites to distribute malware to visitors. To reduce the risk of malware through these channels, we recommend using an XDR product.

Strong Authentication - MFA Everywhere

Using multi-factor authentication (MFA) wherever possible, including:

Maybe the most important of these is to review your production environments for access that is governed by access keys and secrets that don't also require MFA. We want to ensure that access to cloud operational systems requires MFA - and potentially is done through auditable channels.

Many mobile device management (MDM) platforms allow for enforcement of MFA on startup and configuration management in general (eg. encrypted hard drives, etc.).

Although there are valid discussions in the infosec community about the strength of different channels for delivering MFA (SMS vs. Authenticator) the most important thing is to have MFA enabled.

In general, we prefer single sign on (SSO) to MFA. But we need to be careful about the implications of this when an SSO provider gives a long term session token when a session is established. So the devil is in the details a bit with SSO - but at a high level, make sure MFA is required for access to key assets.

Least Privilege and a Process To Deprivilege

If you have developers based in the Ukraine, they may need access to certain things and not others. Based on the elevated risk, it is very reasonable to reassess these and step back to providing access to only what they actually need.

For example, if you have two products, maybe they only need access to the one they are actively working on. Similarly, maybe it is possible to reduce access to a particular development environment and not provide access broadly to AWS resources, for instance.

Another consideration is that you may want to reduce privileges for a period of time either in general, i.e. Ukraine based devs don't need access to production for a period of time, or as a response to specific events, eg. laptop is confiscated during military exercises.

Least privilege is hard and generally under appreciated work when it comes to security - because people complain when they don't have access and it is complicated to establish strictly what access is required for a given activity. Still, time spent here reduces your attack surface in the event that a developer's access is somehow stolen.

Eliminate The Use of Local Secrets

Ideally, developers don't have credentials to production systems sitting on their laptops. Again, the risk here is that a laptop is repossessed and there are secrets on the hard drive that are accessed.

A concrete way to achieve this is to use something like aws-vault and store access keys and secrets in the keychain. Looking in local files for private keys, credentials, etc. is a way to reduce what an attacker can get at if they somehow get access to a running system and can see the file system.

Review Alerting Around IAM and Resource Provisioning

Confirm that alerting is in place to detect changes to your identity management system, whether that is AWS IAM or G Suite or JumpCloud or Okta. A common action taken by an attacker may be to establish other identities they can use in your account. You want to be able to detect this.

Another common attacker action is to create additional resources (eg. EC2 instances) that can then be used to create a lasting presence in your network. Being able to track these, say with AWS Config, or CloudTrail is another important capability.

Physical Security

Honestly, there's not a lot a small developer shop can do to ensure physical security of a team in a potential conflict zone. It may be worth offering short term relocation. Larger companies might provide more secure locations or seek paid protections but for most of our clients, this is not something they are able to think about.


In InfoSec there is an idea of a canary, which is derived from the old idea of a canary in a coal mine. The canary is basically an early warning signal that something is wrong. Although it is hard to think about, it is certainly possible that a team member could be held captive and forced to provide passwords and MFA tokens. Organizations could establish canaries, essentially otherwise harmless looking signals that the person is ok or has been compromised so that their access can be removed.

Some companies use the idea of warrant canaries to signal whether law enforcement is asking them for detailed personal information and asking them not to disclose that they have been asked.

In this scenario, a company could provide a simple check in process that if followed indicates everything is ok, but if missed triggers removal of privileges. Of course, if you do institute such a process, you would want to also establish communication channels and authentication / validation processes for reinstating privileges.

Developer Continuity

An obvious concern is developer productivity and continuity of access. The internet could go down. A laptop could be confiscated. It can be possible to provide a backup network (eg. cell phone) or process for getting a new laptop - but it is probably not possible to fully mitigate the risk of developer downtime. Therefore, we advised our customers to plan for some of this and evaluate projects that have critical contributors and important timelines - and revisit plans to see if they can be adjusted to provide better continuity. Ultimately, we see this as a case where we need to be aware of the risk and mitigate it the best that we can - but not expect to fully eliminate the risk.


For me, it feels surreal to think that we may have colleagues in conflict zones. For many of us though, that has been true for some time and it is probably something we need to include in our threat models and risk strategy. This post tried to highlight some of the specific things that maybe matter more given the types of circumstances we see developing in the Ukraine. It is intended to be an example and to provoke thought. Stay safe out there!

Map credit: Ukraine - Wikipedia - By Rob984, ByStaJ - Location European nation states.svg, CC BY-SA 4.0, Link