In 1999 I was on a flight and sat next to an EE who worked for Boeing on commercial airliners. He said that there was virtually no chance that a cell phone would cause any interference. He said that as far as he could tell the FAA rules stemmed from the FCC that stemmed from the cell carries pressuring the FCC not to allow it. The reason he suggested was that cell phones at altitude have line-of-sight to dozens of cell towers. As airplanes full of cell phones fly through the air they associate and disassociate with cell towers very quickly. The towers have to switch the handsets from tower to tower more quickly than usual causing a lot of network traffic signaling overhead between cell sites. Here's a wikipedia article on this http://en.wikipedia.org/wiki/Mobile_phones_on_aircraft#Cell_...
Thanks! The logo was designed by the talented folks at http://peeble.in/ Not sure what the font is, however you can drop it into "What The Font" http://new.myfonts.com/WhatTheFont/ and see what they think it is.
We're targeting the enterprise market so most of our customers have a security budget that this would fit nicely in. Our model is subscription based, allowing customers to run as many tests as they want. If you look at how much a breach costs organizations it isn't hard for us to justify our price. I can tell you that everyone here at ThreatSim has been in IT for well over 10 years and we're no fans of high pressure sales. Most of our business is based on referral and repeat customers. If you want to know more please fill out the contact form on our site.
Little background here: We're a security consulting company. We do a ton of web app security assessments, network vuln/pen testing, etc. A while back one of our clients (large financial) hired us to do a spear phishing simulation. "Show us how people are still able to get in and show us how they are able to get out". So we did it all manually both the phishing as well as going on site to to data exfiltration to see how we could get around their outbound firewall rules, IDS/IPS, DLP, proxies, sniffers, etc. We figured out how to do all of these successfully and were able to "steal" some fake credit card numbers.
We lost a lot of money on that engagement. :) We went waaay over margin. So we started thinking how can we automate this and make it a repeatable process that customers can run on an on-demand and on-going basis. Security is who we are and in our blood. We we started coding...
And here we are.
So there are two sides:
1. Web based spear phishing engine that sends out "malicious" emails with all kinds of different options (e.g. malicious attachments, links to malicious web sites, 'your pass expired, enter it here!' sites, etc.) We track who clicked on what, who has out of date Acrobat, Flash, Java, etc.
2. Bottom line is that phishers will ALWAYS get people to click on something. No matter what. And the attacker only needs 1 person to do it. Just 1. So let's assume that we're going to eventually get in. We have an on-demand executable that mimics attacker malware complete with ninja-sneaky network tricks that phones home fake credit card numbers, .rar files, all kinds of cool network trickery.
All of the above is run by the end user and presented in a nice web UI so a security guy/gal can make intelligent decisions on where their security is good and where it sucks.
We're super excited about our new service and we hope everyone else is too. Would love to hear more feedback.
We're a mid-level appsec firm, how's that? :) The problem is that high, med, and low end attackers are using spear phishing to get a foothold inside many organizations. This is testing that everyone should be doing today. Read any recent mainstream media article about any breach and Cmd-F "phish".
Yes, one of our goals is to collect industry-wide metrics that will help everyone figure out what the best approach to tackling this difficult problem.
Edit: added URL