Information Security can be a difficult field to hire for. Unfortunately, deception is no exception. While there is no easy formula that can be used to determine if a candidate will succeed or template to compare resumes against, this post will outline some of the things to look for when evaluating a candidate for a deception team.
Incident response
Knowing how incident responders operate is incredibly valuable when designing deception-for-defense. When a decoy alert fires, incident responders will determine whether or not that alert indicates the presence of an attacker; the better they understand the information contained in the alert and the context in which it triggered, the more accurate their decision is likely to be. By designing decoy resources with the incident response process in mind, deception planners can improve the chances the alerts they generate are quickly understood and accurately triaged.
A solid base in incident response can also help deception planners identify gaps in an organization’s security posture that decoys can fill. While it is sometimes more valuable to build redundant alerting capabilities in a high risk and/or high value part of an organization, it is often better to expand visibility into an area where there is none. Engineers with experience performing incident response are more likely to recognize underserved areas that can benefit from decoys.
Offensive security
While familiarity with incident response may be the most important to a successful contributor to a deception program, its opposite, offensive security, is a close second. In many ways incident response and offensive security are two sides of the same coin. Incident responders look at logs trying to determine if any of them indicate the presence of an attacker, while attackers look at systems trying to determine if a misconfiguration can lead them towards their end goal (usually increased permissions, sensitive information, or something else they can profit from). As discussed in a previous post, successful deception is placed where attackers want to go; having experience as an attacker makes it much easier to know where an attacker wants to go.
Another reason a background in offensive security is beneficial to deception parallels incident response; identifying gaps in a security posture (and how they might be filled) is easier with experience as an attacker. As the business’ security matures, deception practitioners with offensive backgrounds can quickly find the next-most-likely path an attacker might use, and place deception in that path.
System administration
In order to protect an environment with deception, decoys have to be put in that environment. Whether the decoys be machines, files, or some other asset on a device, experience with system administration tools and practices is helpful during both deployment and maintenance of decoys.
Deception, in the context of security, can be thought of as building an enterprise environment that just happens to not be used for any business purpose (other than catching attackers). Sometimes that environment sits alongside the business, sometimes it lives within the business, and most times it is a combination of the two. The more deception can integrate with normal system administration practices that the organization already uses, the more likely it is to provide security benefits.
Infrastructure as Code (IaC) / Cloud
Along the same lines of system administration, if the decoys are in a cloud environment, or are cloud resources themselves, comfort with IaC standards simplifies the process of protecting the cloud.
The makeup of the environment the deception team is charged with protecting will determine whether system administration or IaC / Cloud are more valuable skills, and it may change over time. When determining which to target, the team should aim to choose the skill that best answers the question “where will the majority of the decoys we place in the next 12-18 months be stored?”
Programming
While many technologies and environments have commercial solutions available, not all of them have plug-and-play deployment mechanisms. Having enough programming experience to write scripts that can interact with application programming interfaces (APIs) and perform basic tasks on existing infrastructure makes the job of a deception practitioner much easier. Powershell, Bash, and Python are three languages that are commonly used for deployment and maintenance of decoys.
Programming becomes even more valuable the more bespoke a deception initiative is. For deploying decoy machines, decoy files, or decoy credentials, programming is a nice-to-have. For building custom decoys tailored to a specific environment, programming will likely be a requirement.
Wrapping up
Depending on the needs of the organization and the team, the skills listed above may change in their importance. Early in a deception program’s existence, incident response experience is likely the most helpful by far. As the team matures, offensive experience closes the gap, and may in some cases overtake incident response. Even further down the line as solutions become more and more bespoke, both offensive security and programming experience increase in their importance.
Building a well-rounded team with individuals who have some experience in most of the areas discussed and a deep understanding of at least one of them maximizes the chances of long term success.