Follow Lesley Carhart - Full Spectrum Cyber-Warrior Pr.. on Feedspot

Continue with Google
Continue with Facebook


I recently ran across a tweet by the very insightful Fernando Montenegro in which he makes an interesting point about a phenomenon we occasionally run into while examining social media profiles associated with a business:

Do people also find it creepy/sleazy coming across fake LinkedIn profiles when researching a company/vendor? Makes me question the ethics of the company doing it. #analystlife

— Fernando Montenegro (@fsmontenegro) April 26, 2019

In this case the profile in question ended up being associated with a real person, but I definitely agree with Fernando that social media is rife with businesses which build full or partial employee or customer profiles to promote their business. We’ve all read a customer review page for a product where the reviewer profile pictures looked just a bit too familiar. A quick reverse lookup often shows them to be stock art images, bringing the credibility of the review or even the product into question. Clearly, this type of embellishment runs from borderline unethical to outright illegal.

However, there is at least one very valid and important reason for security teams to generate fake employee profiles on web services and social media. In fact, this is such a low-effort, high reward defensive measure that I highly encourage my readers to have a discussion about it in their own organization as soon as possible.

At the most basic, a fake person is much easier to monitor for abnormal activity  – or any activity at all – than a real one.

Most of my readers will be familiar with the concept of a honeypot. While this technology has changed greatly over the years, the principle stays the same. Some portion of a computer network is emulated inside a LAN or in a DMZ. It looks similar to the real environment, and a casual glance shows real, potentially vulnerable systems. Truthfully, the network contains no sensitive data nor access into the real operational environment. However, it can be carefully monitored for scanning, attempted exploitation, and tampering. Observations from the honeypot network can be used to routinely shore up defenses and improve threat intelligence in real life.

Honeypots are one of the few available tools which may potentially allow for detection and response at the “Reconnaissance” stage of the Kill Chain.

The problem is, hard DMZs are slowing becoming obsolete and going away. Today’s corporate networks are typically much fuzzier – large portions of them may be managed services or hosted in the an external cloud. There isn’t a clear “out” and “in” in a set IP space. Adversaries have also focused more on social engineering and “living off the land” and it has consequently become harder to monitor for the targeting of individual employees. It’s also become trickier to lure adversaries into a network-based honeypot.

We can still lure adversaries into a trap, though. Instead of merely providing a juicy technical target, we can create tempting social engineering, phishing, and credential stuffing “human” honeypots. For example: if an adversary’s tactic is to phish people in Sales using spoofed emails, they must first gather a list of target emails from some source – perhaps a corporate website or LinkedIn. While real life sales people have very dynamic interactions with email, people, and the internet, a fake sales person’s behavior will (hypothetically) stay the same until an adversary targets them. So, a security team might choose to create a fake sales representative associated publicly with their company, and closely monitor that account and mailbox for suspicious inbound communications, account harvesting, or brute force attempts.

The sophistication of this fake profile will depend on the level of security monitoring available in your organization and the amount of time which can be dedicated to honeypots. Creating fake employees isn’t a particularly technical undertaking – but it can be a time consuming one. A very basic human honeypot (or “honey person”) might just entail a LinkedIn profile and an associated corporate email box which forwards directly to a security mailbox. Placed in the right departments, this can be a great tool to detect Business Email Compromise attempts, or targeted phishing. I recommend that a typical business create a fake finance and IT person. If your organization does development or design which may be a target of espionage or sabotage, add fake engineers as appropriate.

Creating a more sophisticated honey person might entail the following:

– A (reasonably complete) LinkedIn profile with at least 2 previous “positions” that is allowed to naturally age on the site for several weeks or months with basic posting / “human” activity.
– An associated, standard-convention mailbox which forwards silently to a security distribution list.
– Business card entries for the person on typical contact info / sales lead databases such as Hoovers.
– A basic corporate directory entry (if such information is made public)
– Additional social accounts and activity to further backstop the account and add credibility.
– An unprivileged / disabled Active Directory account for that user (with 24/7 monitoring for usage or alterations).

You may wish to refer to one of my older blogs: 101 Ways I Screwed Up Making a Fake Identity, to get a general feel for the problems that crop up while trying to make fake profiles passable.

Adding in a layer of active directory monitoring associated with the “user’s” account can improve detection for theft of your complete employee or account list, brute force attempts towards email or VPN, or attempts to abuse or escalate privileges. Once again, this will not be lost in the noise and variability of a real human user. It’s a very clear canary that something is going awry. However, keep in mind that this account could also potentially be abused by an adversary if not carefully monitored and restricted.

Human honeypots or “Honey People” are a tremendously valuable element to defense-in-depth which allow for detection of adversary activity from the top to the bottom of the Kill Chain. These “employees” can be created with pretty minimal effort (although convincing ones require similar time and effort to generate). Once in place, their inbound messages, attempted logins, and successful usage on systems can all be set to trigger monitoring alarms and allow for an early warning of malicious activity against real users. Never use these accounts to inflate employee count, capability, or satisfaction. Always consult with your leadership and policy teams first, to ensure you have permission to create fake public personas or accounts.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

A couple weeks ago, I vented my frustration as an ICS security professional at my apartment building forcibly converting to networked smart locks. My tweets were widely misinterpreted, so I’d like to talk a little bit about privacy and security aspects to consider if (when) the property you rent from decides to go “Smart”. To be abundantly clear, I’m not opposed to Smart Home systems – most of us want to live in Star Trek and these devices are a way to a more convenient future. However, there are right ways and wrong ways to implement them, and many substantive privacy and security questions to ask as we move forward into that future.

What’s Your Threat Model?

Before we go any further – when we’re talking about things that impact personal safety, it’s crucial to think about the specific, realistic threats that we (or our families) face. In this blog, I’m going to talk about ways that consumer IoT and Smart Home systems can be abused to cause risk to safety and privacy. If your number one concern for your safety is a casual criminal breaking your lock and stealing your TV, and the loss of your activity data isn’t something that substantially impacts or bothers you, you might decide that a flawed Smart Home system is an acceptable risk (or even a net benefit).

The EFF has a lovely guide on personal threat modeling here. I also enjoyed Sean Gallagher‘s article in ArsTechnica. Always that risk to your person or sensitive data is a combination of threat and vulnerability.

My threat model is not your threat model. I investigate nation state and criminal hacking for a living, and I’m a social media personality. Understand your own, and how security and privacy changes will impact it.

How Does Somebody Defeat a Smart Lock?

Before we talk about how a smart lock can be defeated, let’s talk about a typical US renter’s lock. For years, rekeyable mechanical deadbolt locks with master keys have dominated the US apartment market. Many lessors don’t use high security locks with substantial modern anti-pick or anti-drill protection.  They choose locks because they’re quick, cheap, and easy to rekey and meet codes. Your apartment deadbolt is a deterrent. If you live at ground level with windows, it might be easier for a criminal to enter through one. If you live in a more secure building, it still won’t take long at all for someone with a bit of motivation to bump, drill, or pick the lock.

Smart locks really vary. A lot of their security depends on their implementation, quality, and features. Some of them provide slightly better physical security than a mechanical lock, and some of them may have slightly worse resistance to simple physical attacks. In my case, the lock in question has no mechanical keyhole, so some physical attack vectors simply aren’t there. If that’s your specific risk model, then that lock is an improvement.

Pin-code locks are open to a host of different attacks than keyed locks. Numbers may wear off mechanical buttons due to use. Additionally, pin codes are something that one knows, unlike a key which they have, and therefore they can be somewhat easier to steal than physical resident or master keys via shoulder-surfing or social engineering. It is also possible for a technically adept person to retrieve a master pin code from a some locks electronically without physical damage. It’s important that any landlord installing pin-code locks considers these issues carefully.

Bottom line – a smart lock’s resistance to physical and low-tech attacks totally varies by the lock and how it is installed. Be sure you check into yours’.

However, smart locks, by their nature, also add a great deal of complexity – both in terms of stuff that can fail rendering the smart lock failed locked or unlocked (which may be noteworthy in many people’s risk models), and in terms of network features that add substantial vulnerabilities.

What Happens When we Network the Lock?

Modern smart locks (and many smart devices) frequently connect to a controlling smart hub via two mid-to-short range wireless protocols: the open standard Zigbee, or Silicon Labs’ Z-Wave. In the case of some popular smart devices, a network module is interchangeable to support either. Both of these protocols support mesh networks – meaning, if a device is far from a hub, it can use other devices as relays to talk to it.

In terms of wireless security, both protocols use AES-128 symmetric encryption, but devices implementing both have been vulnerable to some wireless exploitation methods, especially during setup. A big cause of this is backwards compatible devices, and poor or insecure implementation of the protocols by product vendors. While vendors may release firmware updates to fix these issues when possible, the onus is on the device owner to apply them promptly. Patching one’s lock isn’t something many consumers think about.

We come back, however, to the question of threat models. It is certainly possible to attack Z-Wave or Zigbee devices via those protocols, given readily available hardware and software. However, in most cases, these attacks are currently inefficient compared to other attack vectors which we’ll discuss.

The Problem of the Hub

We’ve discussed the security of the standalone smart lock, and the communication method it uses to talk to a smart hub. So far, things don’t seem much more dire than our old-fashioned, master-keyed lock. But that hub has to make decisions about what the smart devices connected to it do. In some cases, a hub may be isolated from the internet and merely make decisions based on local voice or control input. However, it’s much more common for consumer IoT hubs to be connected to the internet. This provides features like remote app-based control, and data reporting, or advanced voice recognition (think, home assistants).

In the case of the rental market, smart home systems provide a few obvious potential benefits:

– Monitoring of utility usage or unsafe conditions (e.g. water leaks).
– Control of occupied unit access for service.
– Control of unoccupied unit access to reduce the need for leasing staff to demo properties.
– Monitoring for subletting or apartment rental service use against policies.
– Faster rekeying on moveout.
– A sexy sell on convenience for potential buyers.

All of those things but one require the hub report data back to some central service. A lot of information about resident lives. Even if occupied unit data is redacted when sent to the lessor, the smart home company must handle data at rest and in transit which may very likely include things like: lock state by timestamp (when is the resident home or on vacation?), guest access, temperature and water usage (when does the resident sleep?), and remotely-configured pin codes to open the lock. As devices become more integrated, this data set will grow and become more telling about residents’ daily activities.  This data is being handled by the hub, then sent to the vendor to disseminate and process. The vendor may also issue commands from the app or the lessor to the hub, such as new access codes.

What’s the Right Way to Do This?

If I were management companies’ security consultant (and I’m not), I’d issue them some firm advice – connect these hubs to a private and professionally secured network (preferably wired). Ensure they’re monitored for intrusions and administrative logins, and physically locked away from resident access. Finally, ensure the hub product and vendor network meet reasonable modern security standards.

Unfortunately, there’s currently a mad dash to get these technologies deployed to rental properties by multiple management firms and smart home vendors, and making those changes costs more and takes more time. What we really see happening across several vendors is a highly competitive push to connect these hubs to residents’ personal routers, so that they they may have a connection to the internet and thusly to the vendor. From my limited viewpoint into deals and investments, vendors who are seriously considering security and doing things right are struggling to meet leasing firms’ aggressive time-frames.

Why Is This a Super Cringe-y Security Idea?

Allowing residents physical access to a consumer-grade smart hub with an ethernet port or wireless interface is always going to pose a substantial product security risk. Even with a responsible disclosure program, potentially tens of thousands of residents will have access to the unit – which may be using some very well-documented services and technologies. Some will be more technically savvy than others. These hubs will almost certainly be aggressively examined and reverse engineered to look for any security deficiencies in the short to mid term. Some firms are simply installing already-exploitable consumer hubs in the rush to market.

Connecting hubs to residents’ personal routers adds another host of security and liability issues – both to the resident, and the vendor. When was the last time you replaced your home router, or changed your WiFi password? Home routers are often old, have few security features, and little or no segmentation between WiFi and physical ethernet ports. Home wireless encryption standards are not currently in good condition and are typically quite crackable by somebody with a $30 antenna and a laptop running Kali Linux. Once an adversary has obtained access to a consumer wireless network, they’ll typically be be able to connect in the future at their leisure.

So now, we’re in a position where a person with some basic hacking knowledge and YouTube can spend some time gaining access to resident networks, then return days, weeks, or months later, to exploit and tamper with the connected smart hub(s). As an added benefit to a criminal, it’s pretty easy to walk by an apartment and guess based by signal strength which SSID it is broadcasting. This isn’t really high tech stuff – or high barrier.

That same person could certainly come through a building with a bump key and break into mechanical locks. However, this typically leaves some physical damage and evidence, and the skill and tool barriers are very different. Again, we’re back to the question of threat model. If someone is stalking or abusing a resident, being able to repeatedly open the lock while leaving no physical damage or evidence (and not having to do anything overtly suspicious) could be very desirable. This is very much in the realm of possibility if these systems are not secured properly.

What About Remote Attacks?

Up to this point, we’ve only really discussed attacks which occur local to the rental property. However, recall that the hub has a direct connection to the internet via an insecure consumer router (or even a cellular dongle with no security at all). This exposes the hub to a multitude of the omnipresent attacks and scanning which occur perpetually on the internet. Most low-end consumer hubs have some sort of web interface or terminal interface for standalone management or configuration.

It is clearly absurd to expect everyday residents to have the technical knowledge or resources to secure a hub from these types of attacks, particularly as their consumer routers age.

These hubs will be scanned and attacked on any and every port, using any available service. Repeatedly, over time – and potentially thousands of units per vendor. They may trivially be indexed in Shodan and left searchable and exposed.

Without being secured on a private network with proper commercial security, these hubs will be attacked, and the only question is how long and effectively they will withstand the scrutiny.

Then, There’s the Vendors’ Security…

Let’s move back to the question of the vendor to whom a smart hub is sending data. I’ll just give all the vendors in the space the benefit of the doubt and presume that they do this using strong encryption – anything else would be nearly criminally negligent. However, even encrypting the connection poses security difficulties. If certificates or credentials used to access the hub and connect it to the vendor are hard coded anywhere on the hub, they’ll become a juicy target for reverse engineers and malicious hackers, and may become an avenue for attack against other hubs or the vendor. Careful product security design and best practices are critical, as well as routine and detailed product security audits.

We’ve established that for system operation, these smart home vendors are going to have to handle a lot of private and telling data about residents – both in transit and at rest on their systems. This isn’t a trivial responsibility – especially as this service becomes more ubiquitous. All of the typical commercial concerns for securing sensitive data apply. Regardless of cloud or physical infrastructure, the vendor has to implement a strong security program to include real-time monitoring, structured patching, security auditing and assessment, formal identity and access management, proper data encryption, incident response, data breach preparedness, anti-phishing, and employee background checks. The vendor must simultaneously ensure the security of any apps they provide, and proper secure development and auditing of any devices or hubs they manufacture.

Essential Security Process Documents a Smart Home Vendor Should Have

A company handling access and sensitive private data in transit or at rest should have (at a bare minimum) these formal, written processes in place:

  • A data breach response plan (in case a system deficiency or hack exposes private data)
  • A cybersecurity incident response plan (in case an intrusion is reported or detected) – and they should make it clear if incident response is handled in-house or retained.
  • A vulnerability reporting program (so system or product deficiencies can be responsibly and effectively disclosed).

Not seeing one of those processes provably in place is a huge red flag to me as a person who investigates and researches security incidents. They should all be mandated by property management companies who are contracting with smart home firms.

Do keep in mind that these are in addition to the essential technical security measures noted in the previous section.

Hacking Goes Both Ways…

While exploited or poorly-secured hubs may provide a handy attack vector against the smart home vendors’ systems or other hubs, they may also provide a convenient route for hackers into residents’ private networks. If the hubs are not properly monitored or secured, they could certainly be exploited via the internet in the future to conduct reconnaissance or attacks of other devices connected to the network. This poses a potential mire of liability for the smart home vendors and management firms.

If a lessor firmly directs residents to connect smart hubs to their networks, which are then exploited to cause infection or hacking of the resident’s personally-owned network, who is financially liable? What if the resident conducts professional or sensitive work using the network, and another company faces damages or intrusion as a result? These are legal questions regarding liability which I do not have the expertise to answer, but they are deeply troubling.

But, Lesley – Everybody Has an Alexa!

Consumers typically have a choice to purchase or not purchase their own smart technologies. Many people opt for the convenience that Alexa or Google Home provide. They may even make an added risk decision about connecting access control devices to their smart hub. However, I do caution that while both Alexa and Google Home clearly pose privacy and security concerns, they are both backed by very large, enterprise-grade product security teams and network security teams. Yet even high-end, well- supported smart devices are sometimes hacked.

I would highly encourage any lessor or tenant being approached with a smart home system – particularly one controlling access – to investigate if the vendor can realistically meet the same standards, or at the minimum – fundamental and necessary standards of cybersecurity. Ask substantive questions about their security program, security staffing, and data breach and incident response plans.

Finally, those Pesky Privacy Concerns

Many of the people objecting to these systems outright are doing so merely because they don’t want private data about their daily activities sent to a third party at all. I can certainly appreciate this. Again, I’m not a lawyer. I will note that I couldn’t find any precedent for cases involving landlords forcibly sending behavioral data on residents to third parties, or reselling it. Of course, this desperately needs to be discussed and explored as more and more data about our daily lives is catalogued, and China rates their citizens based on similar data points.

At this time I have absolutely no proof that any company involved in these migrations is monetizing resident data. In fact, the companies I spoke to are being careful to redact some resident behavioral data once it arrives at lessor consoles from vendors. That does nothing to reduce security concerns, but it’s encouraging from a pure data privacy standpoint.

I will note that that it does appear to me that property management firms are being unfortunately remiss in not getting in front of these obvious concerns in writing – establishing clear and written privacy policies for their usage of the smart home data and data ownership with regards to the vendor and device manufacturers. Making people with privacy concerns really uncomfortable about living in their homes is a great way to lose residents and degrade confidence. Clarifying privacy policies is a relatively cheap and easy reassurance to provide.

Regardless, my expertise is in cybersecurity, and I’ve chosen to focus on the potential security deficiencies and exploitablity of these systems. I encourage privacy advocates to investigate and discuss those aspects as well.

Where is this Headed, and Who is to Blame?

I am a security professional. I have limited visibility into inner political workings of property management. I can only make educated guesses based upon press releases, startup funding rounds, and conference talks. But honestly, after spending a couple weeks looking into companies who are purchasing rental smart home technologies and vendors selling it, I can’t fault the individual employees of the vendors producing the tech, too much. This is the hot new thing – smart apartment technology has been discussed in depth at high-profile conferences, and management companies seem eager to get it deployed across thousands of units in astoundingly tight time-frames. The bottom line is that management companies love these systems, many residents find them cool, and vendors are being pushed hard to produce. The voices of security and privacy-conscious residents are likely to be drowned out, until a data breach or security incident causes substantial attention.

I think there are definitely ways to do smart apartments right. I was incredibly impressed by a couple companies I have no affiliation with that reached out to me after my tweets about this issue, interested in my security concerns. There are certainly both vendors and management companies that are carefully evaluating these problems and building mitigations.

At this point, however, this seems to be a freight train far larger than I as an individual ICS security researcher can hope to stall. Projections show systems from several vendors deployed into hundreds of thousands of US apartments in a couple years. I would simply implore management companies consider all the implications of these systems carefully, and invest a relatively small amount of money in installing them securely and ensuring vendors have the human and financial resources they need. I am, as always, willing to assist as much as my free time and resources allow.

What’s the TLDR?

If you’re a tenant in the US, it’s very likely that a management-provided smart home system is headed your way in the near future. Carefully evaluate your family’s personal threat model, and consider the plausible digital ways which these systems could be exploited.

Spend some time reading into the vendor. Respectfully and courteously encourage your property management company and their smart system vendor to adopt industry best practices in securing smart hubs physically and digitally, the networks they are connected to, and and resident data at rest and in transit in their infrastructure. Request your property managers clearly and decisively address privacy concerns such as data ownership and resale in writing. If solid answers in writing don’t assuage legitimate concerns, consider politely seeking an option to opt-out – and make your threat model clear to them, if you’re in a sensitive situation.

These systems are the future – let’s do them right, for everybody.

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Ever wondered if your conference talk proposal measures up? I definitely do, every time I submit to a conference.

Over the past week I reviewed over 600 call for paper submissions for the Derbycon information security conference. This was definitely a unique experience – I had participated in review boards in the past, but never on such a massive scale. I had to be considerably more critical that usual because of the limited number of speaking slots available versus the huge interest.

I came out feeling better about my own submissions, but with a lot of food-for-thought about what I can improve in the future. Many of the submissions I reviewed were excellent, and I had a very hard time making final decisions about which ones were the best. However, other submissions really needed some work.

Let’s talk about the biggest problems I saw:

The “Couldn’t Put in the Effort”

There was a substantial number of talk proposals with serious spelling and grammatical errors, lack of capitalization, and even incomplete sentences or mistakes in copy-pasting. If you’re proposing a talk you intend to give to dozens or even hundreds of people, I have strong reservations about your preparation when you can’t do even a cursory check of your paragraph-long application.

Let a friend, colleague, or family member put a second set of eyes on your submission. It shows you care.

The “Didn’t Read the Instructions”

Call of paper submissions usually follow a specified format. In this case, a synopsis and an outline were requested by the conference. Many submissions I reviewed did not include one or the other. In some cases, the submitters provided long bullet lists or paragraphs instead of a tabbed outline that concisely described their talk proposal. In others, the synopsis was well over 1000 characters. After 4 or 5 hours straight of reading submissions, it was a little much to take in.

Once again, a second set of eyes is really important to ensure you followed the instructions properly. I definitely notice attention to detail as a reviewer.

The “I’m Not Quite There, Yet”

Similarly, there were numerous talk proposals which proposed vague hypotheses or very general thoughts about what might be interesting. I agreed that some of the ideas sounded intriguing, but they weren’t fleshed out at all. In some cases, the submitter outright stated they hadn’t researched the topic or implemented the idea, yet. This was a problem because I couldn’t be certain they would complete their research and report in time, and their hypothesis could be incorrect or correct.

While I might be able to give these submissions more leeway in a smaller conference, I had to give preference to talks which were thought through and reliable.

The “Flavor of the Day”

The hot topics in information security in 2018 are apparently: MITRE ATT&CK, container security, and hiring and training talent. A massive percentage of submissions directly related to these topics. This required the submissions on these subjects to be engaging, thoughtful, and well written to stand out. Unfortunately, numerous submissions on these topics were pretty high level and vague.

Always do some background research on recent conferences to find out what “hot topics” in the field are and understand if you’re proposing a talk on a subject that has been extensively spoken about. Is your twist on it adequate to stand out and be useful? What’s your hook to capture the imagination of attendees and reviewers?

The “Soft Skills are Easy, Right?”

Everybody gets burnt out talking about highly technical stuff all the time, and at some point we all propose a talk on soft skills, team dynamics, or personal success. This is fine – soft skills are important to any technical field. However, be very certain that you’re spending as much effort on your soft skills talk proposal as you are on your technical proposals. I saw numerous submissions that included short, vague outlines of team dynamic or career progression topics. While these subjects matter, talks on them require equal effort and fleshing out.

If you’re going to submit a talk on why physical fitness is important to one’s career, to an IT conference, please ensure you’ve really thought out how and why it is important and express that well to the review board. Additionally, psychology, health, and social sciences are real fields that qualified people study for years! Being technical experts don’t make us inherently qualified to talk about them.

The “Wall of Text”

On the opposite end of the spectrum from vague and incomplete talk submissions, there were the fleshed out but incredibly dry and rambling submissions. A peril of being academic or extremely technical is often forgetting your audience.

While I’m a subject matter expert in several areas of information security, I certainly don’t know minutiae of every conceivable niche. Many submissions I reviewed were focused on an incredibly specific and highly technical subject, and provided no high-level synopsis or explanation. Ensure your synopsis is comprehensible to a general professional in your field, even at a management level. The longer and more technical it gets, the more crucial a coherent synopsis is.

The “Big Fish, Small Pond”

Some of the very best submissions I saw that were engaging, well written, and unique were submitted to the Stable Talks track. I was stuck wondering how much of this was imposter syndrome, modesty, or gambling with the odds.

If you’ve got a fleshed out idea that your peers and community have given you a positive opinion on, but you simply don’t feel experienced enough to submit it to the conference proper – you’re probably suffering from imposter syndrome. Do a little bit of introspection and talking with mentors. I can absolutely tell you with confidence that many of your submissions this year were superior to the standard talk track ones. Additionally, your odds of being selected were not significantly higher in Stable.

If you’ve 5+ years of experience working professionally in information security, it may be time to considering move up and leaving space for the new folks.

This is not a criticism of applying for Stable Talks. They’re a great place to get your feet wet in a shorter format. Just consider their purpose and your topic and speaking ability.

The “Why is this Important?”

Finally, many submissions really failed to intrigue or inspire curiosity. A CFP submission gives you a very short opportunity to capture the interest and imagination of the review board. We’re trying to decide if a talk is fleshed-out, interesting, and useful to the audience.

Quickly grabbing our attention with a well-written hook that makes us want to learn more is key to doing this effectively. The best submissions I saw caught my eye in the first sentence and made me want to read more.

The “I’m Cute, Pick Me”

I didn’t just title this blog to irritate folks. I really did see talk submissions with click-bait titles! Be very, very cautious about jokes in your submission that might miss their mark given a diverse review board. Nobody’s joke will ever be funny enough for me to select their talk without all the other required boxes being checked. It’s great to be clever in your title and your hook – just be cognizant that a pun or cultural reference might be misunderstood. Think through those choices carefully from multiple viewpoints.

It’s fine to specify your unique perspective or qualifications to speak on a particular subject. However, be cautious about turning exposition into bragging. It’s unlikely that referring to your accolades, career success, or certifications will change my opinion if your submission is otherwise lacking. It may actually cause me to be more critical – I inherently expect a PhD-holding executive to write better than a college student.

Finally, inserting your name or strongly implying who you are in a ostensibly blind review submission also really violates the spirit of a fair and equal board, so please don’t do it.

I hope you find these tips useful as you submit to academic and professional conferences. Happy CFPing!

  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Infosec Resume No-Nos - YouTube
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview