Injects are consistently called out as the weakest part for teams within the Minnesota State Competition. Given that they are worth ~40% of your total points, it's important to understand how to submit a good inject response. Communicating effectively is critical for any security role. So despite this being the "boring part" the ~40% weight for scoring makes a lot of sense, and I think it's fair. A 40% weight shows how important it is to get your point across, to clearly explain rationale for decisions, and how they'll be executed. Finally if you submit an Inject late, it does not get scored. So you want to ensure Injects are submitted on time.

What Is An Inject, Anyways?

Backing up a bit, I want to reiterate what an Inject is supposed to simulate. Most folks reading this likely know already, but I want to make sure that everyone's on the same page before we continue. Injects simulate changing business requirements that your team now must become compliant with, even if it's at the expense of "better" security. Injects show who is giving orders who at the bottom of the page and if you pay attention, they are almost always management or executives. In most organizations, it's expected that management makes decisions, often with individual contributor (think regular IT employee), team, or stakeholder input. However, the final call is usually up to management. Once the call has been made, that's what you'll have to work with whether you like it or not. The competition reflects this reality in a fairly brutal manner. Injects, especially at Regionals come fast and hard. They give you far less time than you realistically would to accomplish the goal, but that's kind of the point. To throw students into a crucible and ready them to become seasoned cybersecurity professionals.

Anatomy of An Inject

Next I want to cover what an Inject looks like with a few examples. There's the obvious stuff shown in bold, but there are other bits of information that I want to highlight too, which are shown in screenshots below. These are from the Midwest Regional Competition in 2019. I won't be supplying the entire repo I have since it was taken down by request from one of the competition organizers, but I got it from a guy who knows a guy and so on. I also know that there are teams that exfil these and study them for next year. This may technically be against the rules, but it's not my place to police that.

Inject 9 - Required Services

Apart from all the clearly defined portions like team number, time to complete, etc. I highlighted all the relevant information for this Inject. Injects contain instructions that must be completed, proof shown of completion, and the Writer must respond to these Injects to address the requests listed here. Fortunately, Injects often contain tasks that are helpful in locking down your environment. Especially in the case of this one, where essentially the competition directors are mandating that you get your firewall rules locked in before we can start causing havoc. You can see with the highlights that the request is pretty straightforward, if you break it down.

1. Create a table of services by host that can be reached externally (scored and customer/orange team accessed services).
2. Block services that are not in that table by port and transport protocol, or by application protocol.
3. Take screenshots showing that you did it.

That's really it. There's no reason this can't be done in 90 minutes. You were given the team packet ahead of time, and it contains the scored services. Most firewall admins would likely have the table handy for rule creation anyways, so make any final adjustments and you'll be off to the races. Especially, given scripting is allowed nowadays. It's also early enough that Red Team may be staying it's hand still. However, since this is Regionals I could be wrong about Red Team activity. Let's look at another example.

Inject 37 - Email Security

This Inject covers email security, specifically anti-spoofing measures that can be performed with DNS. This is essentially a test question in disguise. Also, what's interesting here is that they don't specifically call out a need to implement, just come up with a plan. So a little research can tell you what all 3 of these records are for, how they work, and how to implement them. Given that Regionals contains actual users who may click on Red Team payloads to the email boxes, it's still probably a good idea to implement them, even if it's not required. So you'd want the following in your reply:

1. A high-level plan explaining the outcomes of implementing these DNS records.
2. A high-level plan explaining the implementation of these DNS records.

Onto the final Inject I want to analyze.

Inject 23 - Org Chart

This one is again, pretty straight forward. It's looking for an org chart that explains what it is that the people on your team do in their roles, and the skills required to fulfill the duties of the role. You can use something like Visio or Draw.io to create this chart and fill out most of this information here. When your team is assigning roles for the competition season, making an org chart can help identify chain of command and clearly define what people on the team should be working on, hopefully mitigating interpersonal issues before they arise. Here's an intentionally poorly done example of an org chart.

The reason this is intentionally poorly done is so:

• You can't just take what I wrote here and submit it without any work yourself.
• It still gets the idea across in a fundamental sense.

This chart shows the leadership structure, but you can definitely improve on what I have here. Listing the number of current positions, for instance. Maybe you want to remove the backups into the memo instead of on the chart itself. You may want more positions on here. Whatever best reflects on how your team functions, is what should be shown here. So the Inject response should have the following info:

1. The actual, not crappy org chart.
2. A list of skills that each position should contain. (Think of it like a job description).
3. What positions are backups for other positions.
4. A memo (email) stating if you have enough staff or not.

Everything that isn't point 1 should probably be done in the memo itself, rather on the org chart. But, at the end of the day, it's up to your Writer on how they want to proceed.

Inject Responses

So I grabbed 3 different Injects to show some variety for types of Injects, and how they need to be completed in different ways. Injects tend to be similar year after year, but there are some that change. The biggest thing you can do to make responses a lot faster is to template out what you can. This also ensures consistent reporting and generally increases the quality of Inject responses overall.

I also want to make a call out regarding using AI services for submitting Inject responses. Large Language Models are incapable of reasoning, and therefore are not suitable to properly compose an Inject response, or any other fact based document. They "hallucinate", which is excellent an PR term for the bot unknowingly lying with extreme confidence. If the Competition Organizers think your Inject response is generated via an LLM, they are going to throw it out. AI can be useful, but because it's inherently unreliable you cannot use it as a source of truth. You still need to know and understand the subject matter to be able to verify it's output. Additionally, anything that is said or processed by these AI services is typically fed back into the model, meaning you are typically leaking confidential data to these systems. This can have massive repercussions for you and the organization you work for. This isn't me trying to say "AI Bad. Fearmongering grumble grumble.", but I want to note that you have to be careful on how you use it. Certainly not for anything sensitive. Anyways, tangent over. Back to what I was talking about before. The first inject response example I want to show is the password policy Inject.

Inject 18 - Password Complexity Requirements

Note that this is different than the first one linked in the previous section. The reason being is that since I am not in the competition environment, my firewall rules at home are different than what you would see in the competition. For this Inject, I have both a good and bad response to show as examples.

Terrible response

Here is a response that's just plain bad. I have, unfortunately seen something like this before.

You will not gain any points, or very few points for this of the competition judges are feeling generous. This is a waste of time for all involved. Don't be this team.

Acceptable Response

Here is the "good" response, using my Homelab password requirements as the example. This can still be improved. First off, a box can be drawn around the relevant bits of the screenshots to highlight specific implementation details. I could actually have the policy implemented in a manner that's compliant with CIS benchmarks or some other compliance framework. You probably should have screenshots from all different types of systems on there, and it would be wise to caption screenshots. That's just the stuff that comes to mind first. This response may not get all points, but it certainly will get you more than the previous one.

What it does correctly however, is also pretty important. It's clear who the memo is from, who it's going to, and what it's about. Most importantly, it's straight to the point with proof of technical implementation. If you can get your point across clearly and concisely with management, it's immeasurably useful to them. They are going to like you a lot more knowing that you are not someone who is going to waste their time.

Inject 37 - Email Integrity

Once again, I will answer this one with my Homelab. This is the same Inject as the second one in the previous section. To prevent the need to scroll up here is the screenshot again.

Repeating what I said earlier, this Inject covers anti-spoofing measures that can be performed with DNS. Essentially a test question in disguise. To respond to this, you will want the following:

1. A high-level plan explaining the goals and outcomes of implementing these DNS records.
2. A high-level plan explaining the implementation of these DNS records.
3. Explain why these records are being implemented.

Good Inject Response

Here is the response I have written for this Inject. The only difference is that I wouldnt't redact the domain in my actual response. This response is significantly better than either of the previous ones. It's clear about what DNS records need to be implemented to perform which portion of the anti-spoofing measures, the screenshots plainly show which portions of the implementation are relevant, there's a brief and high level overview of what each piece of the anti-spoofing puzzle accomplishes, and finally the response opens the door for additional conversation and adjustment, if required. This is a good Inject response. One that I managed to put together in about 15 minutes at most. Realistically it would have been faster if I was sharper with email security fundamentals. When the competition organizers are talking about getting high quality Injects, this is what you should be using as a standard. Like anything else, this can of course be improved and is subject to opinion. Onto the last Inject response.

Inject 23 - Org Chart

Like the previous example, this is directly taken from the overview section, just sans highlights. This one doesn't really have a technical component to it, just personnel. That makes it both easier and harder to answer, in different ways.

Inject Response

Note for this Inject response, I am going to use the abridged org chart I was showing off earlier as the guide for how I respond. When you submit a response for this Inject, you will want to have the complete team mapped out. Here is the response I would submit for this. It directly answers the questions that are posed by the Inject, and contains the org chart requested. It may not be a beautiful response, but it should get the job done.

Inject Response Guiding Principals

So, the recipe for a good Inject response is pretty simple. First off, create a response template. It'll save you precious minutes per response to not have to type out the header and footer, especially when you have 60 of them for the duration of a competition. Secondly, analyze what the Inject is asking for and answer based on the those asks. Thirdly I want to introduce something which is championed by BB King of Black Hills Information Security that I think we as an industry need to do better. Taking the written word and moving the goal from "Easy to understand" to "Hard to misunderstand".

I first heard this concept earlier this year and I have since taken it to heart. "Hard to misunderstand" is the guiding principle for how I write nowadays, because it cuts down on the amount of required follow up and prevents confusion from happening in the first place. This results in saved time for everyone involved in communications. Now that doesn't mean I get it perfect every time, but "Hard to misunderstand" is the goal I generally shoot for and I hope that it comes through in my Inject responses. I hope that teams use this post in the future as a guide on how to improve Inject submissions. I'm tired of hearing competition organizers complain about bad Inject responses, and I think correcting that trend can help take Minnesota teams back to the National Competition.

If you found value in reading this, and would like to meet and network with other CCDC competitors, please join this Discord server! I am there alongside students, alumni, coaches, and other CCDC volunteers to help students succeed in the competition and in their careers once they finish their time in the competition.

Changelog

2024-11-20: Fixed some grammar issues, and removed references to my old domain in documentation.

2024-06-05: Added link to Red Team article.

2024-05-17: Added content about AI generated Inject Responses.

2024-07-16: Removed references to a now-canceled post.