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 (securityprogram.io) and AWS Compliance (jasp.cloud). One thing I will say, I'm all for using API's and open tools like steampipe.io 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.

Conclusion

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:

Conclusion

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 securityprogram.io 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 securityprogram.io.

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 securityprogram.io, 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 info@securityprogram.io 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 SecurityProgram.io

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 securityprogram.io.

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 securityprogram.io 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 securityprogram.io 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 securityprogram.io.

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 securityprogram.io 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 securityprogram.io 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 securityprogram.io.

Securing Tech Workers in Ukraine

Although most Jemurai and securityprogram.io 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.

Protections

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.

Canary

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.

Conclusion

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

Feature Spotlight: Risk Register

On some level, the whole point of a security program is to manage risk. In securityprogram.io (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: https://threatmodel.jemurai.com.

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:

SMISHING Text

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.

AT SCALE

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.

CONCLUSION

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

SPIO User