|
I am trying to understand how iSecure detects the good from the bad packets.
If not using signatures and not needing training to know what is normal, then how?
This capability (not using signatures, and not needing a "learning mode" for a QoS-based defense, which in effect makes the dDoS attack successful, since the overwhelming dDoS traffic still drowns out the regular traffic when 'throtteling' via QoS), sets iSecure apart from the competing products. It constitutes the "special sauce" worth patenting, worldwide ;-)
Basically, the conjunction of the real-time bit-stream inspection engine and the real-time decision engine works in an intelligent way (vs. simply comparing against signatures or learned traffic behavior), by application of an algorithm, which was developed over several years. Practically, the bit-stream inspection engine analyzes all packets flowing through iSecure (as an in-line scanner), and presents its findings in 'bit slices' to the decision engine. The decision engine then processes packets in a double-parallel fashion: several bit slices are processed at the same time, and each runs in parallel through the algorithm. This algorithm could also be seen as a matrix of criteria, which triggers flags, in conclusion making the decision if the packet (i.e. sum of bit slices) is good or bad, thus allowed through or dropped.
The real-time performance is the total performance of both bit-stream and decision engine, and in total 6 nanoseconds (best) to 6 milliseconds (worst, under 100% bandwidth utilization, for each of the models currently available 100 Mbit/s, 400 Mbit/s, and 1 Gigabit/s true throughput).
It took the development of a new approach (new technology) to find a solution to the threat of dDoS attacks. All commonly used techniques use older, existing technologies, and have failed to provide an effective solution for many years (the dDoS problem is as old as the Internet & networking in general). The first design steps taken towards the development of the iSecure product date back to 1989.
By the way, the principle of this technology can also be applied in other areas (see future product plans). Both the bit-stream inspection engine as well as the decision engine can be modified to inspect for and decide on different data sets (packet data payload vs. header/frame analysis and recurrence), which makes it ideal to build an anti-virus solution, which for the first time would not depend on the development of an anti-dote for each discovered virus/worm, and downloading the anti-dote in a timely fashion to millions of computers (studies show, that barely 2/3rds of enterprise machines perform daily updates, and much less so in remote users - here a recent report from April 29th for your information).
Another planned application for the iSecure technology is defense against unsolicited e-mail (Spam) --- based on a different, pay-load inspecting bit-stream engine, and a modified decision engine, using the same underlying technology principle, it can eliminate SPAM. Is there a market for that? Check your e-mail "In-Box" ;-) - none of the existing anti-Spam solutions have a decent success rate ('bad'=Spam E-mails go through), and come with a lot of false-positives ('good' e-mail identified as 'bad', i.e. not delivered for containment and manual review).
In all tests of iSecure, we did not have a single false-positive.
|
|
|
And if your product is inline, how confident are you that customers will accept it
(as potentially another point of failure or bottleneck)?
As an in-line scanner on a critical connection (towards the Internet or on internal networks), iSecure is certainly a critical component. Even though it does represent a risk of a point of failure, the benefits far outweigh the risk. Not only does it prevent dDoS attacks (the only way to effectively do that is as an in-line scanner), it also cloaks the infrastructure (information gathering attempts through port scans and fingerprinting no longer work, leaving the potential attacker completely in the dark what kind of hardware / operating system /application software he or she is attacking), and protects the firewalls and other systems against network attacks (a by-product of the dDoS functionality).
Firewall protection: ALL traditional fire walls (>95% of systems deployed) are susceptible to attacks against their own TCP/IP stack, especially through dDoS attacks (some newer designs, such as NetScreen, make an attempt as another in-line device). In tests, we have demonstrated that iSecure eliminates that risk (one reason why we are engaged in licensing discussions with one of the top firewall vendors, and get so much attention from the NSA - which is the main driver and funding source for the DoD SPOCK program, which Melior is now a member of - the only! company in the program without a civil service contract, among companies such as IBM, Secure Computing, etc). One example (we can supply more): a Checkpoint FW-1 attacked by Synk4 (a popular and freely available dDoS program, and one of the worst, which kills its target with a low-bandwidth attack in seconds) becomes instantly unavailable; if the same firewall is also equipped with Checkpoints "SynDefender" program, a free add-on provided to licensed customers for dDoS defense, a Synk4 attack destroys the firewall, requiring re-installation of the software and license keys, and restore of the firewall rules, resulting in several hours of down time. We can also discuss the "TCP Intercept" function in the Cisco IOS software, which maintains a stateful table, thus making it easily attackable (and brings down the entire router with it). Fixing what we consider a design flaw requires a re-write of the IOS software - and with Cisco's history (example1, example2, example3) of providing IOS updates, not likely to happen (no pun intended; just a realistic view of the market space).
The market has seen a lot of products making claims of successful dDoS defense, which all fell flat when asked to prove it. With a few reference clients deployed (we are working on a variety of such accounts), we are confident to overcome the skepticism towards an actually working solution.
With future development, we will also provide a redundancy option to mitigate the minimal risk of failure (the system uses few moving parts, and is likely to have a low failure rate). Since it cannot be compromised (undetectable, has no MAC or IP address), other forms of failure (besides breaking HW) are not an option. We also sell a mandatory maintenance contract with each system, to ensure a quick replacement in the event of a HW failure.
|
|
|
THIS IS MORE OF AN INVESTOR QUESTION:
Your revenue and EBITDA projections are extremely aggressive, given (as you point out) that other well-funded competitors have not been able to generate much revenue. What makes you think you can sell a product (and at quite a high/low price point) so rapidly?
Revenue & EBITDA projections aggressive?
Actually, we consider the forecasts conservative. The forecast only shows the simple replication of the existing systems (without consideration of product enhancements) in mass production, to a world-wide market, consisting currently of about 600 million Internet connections (last IDC estimate) with a monthly growth rate of 15% (worldwide).
Along with the potential to sell iSecure for the Cloaking feature alone (assumption 1/6th of the connections see value in cloaking, currently not available in any product = 100 Million iSecure systems), sales should fairly easily exceed the 50,000 iSecure systems we forecast to sell over the duration of 4 years. The revenue projections do not include any forecasts for sales based on the cloaking function.
Product development during those years will likely add to the sales figures:
The next development stage (Q1 or Q2 after funding) will include modified software, which allows iSecure to protect IPSEC devices, such as VPN Gateways, during the IPSEC protocol initiation phase (RFC/Jan 2003, Background) (prior to establishing the IPSEC tunnel). No other product in the market can handle protection of the initiation phase (to our knowledge, and we have looked), which is the reason VPN gateways are located outside of firewalls and DMZs (or require the fire walls to keep huge holes open to allow UDP port 500 (IKE - Internet Key Exchange, RFC, Background, Exploit) and associated TCP ports, thus defeating the purpose of a firewall). With this software update, iSecure can be deployed in front of IPSEC devices, and for the first time protect them. The revenue projections do not include any forecasts for this product feature.
Adding different interfaces to iSecure (such as Fiber ports) is a quick (i.e. uncomplicated) development step (Q1) expanding the options for deployment.
After Year 1, the anti-virus version of the iSecure technology should be complete. To not re-invent the wheel and utilize anti-virus detection and prevention techniques already developed, we are already engaged with the #2/#3 anti-virus vendor for a licensing/joint venture arrangement. The revenue projections do not include any forecasts for this product line.
Also after year one, faster versions of iSecure for bandwidth beyond true 1 Gigabit/sec should be fully developed. We envision this will require the code to be embedded in a hardware platform (via ASICs and/or different processor architecture), and we have located a few potential partners, whose solutions we could incorporate into iSecure to avoid significant development cost for this advanced version designed for high-end carrier protection. The revenue projections do not include any forecasts for this advanced product line.
Cautiously projected for completion after year 2, the anti-Spam version of the iSecure technology should be completed. This product development plan is currently on the back-burner, as we concentrate on the core business at hand, get funding, start selling iSecure in the US & EU, or US, EU, and worldwide (depending on the initial funding amount - only one round required), and focus on the product development plan for which we have the solutions at hand.
Why have other vendors been unable to make noticeable sales?
The answer may sound a bit arrogant, but is not meant that way. Based on feedback from potential customers, who have tried out all other products as well, and our own comparisons, the simple answer is the other products do not work. iSecure does.
To be more precise, the main differences between iSecure and the other products are:
1) competing products recognize mostly only known forms of attacks; a slight modification to a known attack allows it to bypass the protection, as do new, i.e. unknown attacks (dDoS attack tool development is on the increase, same as for virii/worms; a May 2001 study by CAIDA - Univ of San Diego Supercomputer Center - showed a weekly attack rate of 4,000 dDoS attacks on the Internet; article included, paper and mpeg demo video on the CAIDA web site). Thus competing products are only partially effective - not to a degree to make a sale. iSecure defends against all known and unknown dDoS attacks.
2) response time is too slow. The very best is a 4 minute response by Arbor Networks (and not for all attacks, just some). Some solutions present suggestions to add new Access Control Lists (ACLs) based on a detected attack to a router, which then need to be reviewed and implemented by a human after he/she has been alerted by e-mail or pager. dDoS damage is done within seconds. iSecure defends in real-time (6ns to 6ms).
3) competing products require significant architecture changes, competing with or replacing existing firewalls, routers, and intrusion detection systems. iSecure compliments existing infrastructure and protects firewalls, enhances IDS systems, which do not get overloaded with bogus traffic, and enables customer staff to review firewall logs more efficiently with fewer (of the expensive) senior staff (because logs are smaller, contain no bogus traffic, staff can concentrate in less time on the important logs).
4) competing products are not easy to deploy. Customer needs to dedicate significant staff resources for planning, deploying, configuring and maintaining these systems. iSecure is easy to deploy ("plug & protect" --- we don't like to use the term "plug & play", it sounds too easy and plays down the significance of iSecure, and works right out of the box, not requiring configuration; though configuration is an option to adapt to specific customer requirements).
So, even though no significant sales have occurred in the space, there is a reason for it. And with iSecure, we are confident not to run into delivery obstacles (it works). [If you allow me an analogy for illustration if the objective is to drive from point A to point B competing with a fast automobile, the competition uses an underpowered train, for which the tracks need to be laid, and the fuel supply is not sufficient to last the distance. iSecure drives the entire distance in a racing car in record-setting speed, while offering other functions along the way, and arriving well before the competing vehicle.]
iSecure Pricing
Compared to the competing products, we are pretty much in the same price range or lower; though iSecure actually works, and we could thus probably driver a higher bargain (the buyer does not need to know that we already sell at a 80% gross profit margin at this price level), we felt that this pricing is more beneficial. We want to keep the barrier for entry for the interesting target markets as low as possible a large financial institution in the US needs about 200 iSecure systems in a product mix of 100 Mbit/s and 400 Mbit/s systems, resulting in an average investment of $6.5mm. Government agencies are looking at higher number of systems, as are European financial institutions (being universal banks compared to US institutions, and thus more widely spread). These deployment numbers stem from the banks we tested with in the US and EU. This level of investment represents a reasonable expense to avoid downtime, revenue loss, and PR disasters (think BofA losing all of its 13,000 ATMs on Superbowl weekend), comply with the provisions in the Gramm-Leech-Bliley / HIIPA acts, and within a budget cycle not requiring long-term allocation. At the same time, it keeps the iSecure systems affordable for the small- to midsize deployments in the mass markets (we have been asked if we leave money on the table with this pricing structure, which, as you can see, is not the case).
Given our high gross profit margin at this level, we rather sell more iSecure systems at a reasonable price point, than fewer systems at a very high price point. In the long run, the customers are more satisfied (do not feel gouged by unique technology they cannot otherwise obtain), and allows us to penetrate the markets (dDoS, Cloaking, IPSEC protection) quicker and establish market leadership. A relatively decent price point (besides superior technology) allows also for better in-roads in the existing markets of anti-virus and anti-Spam (for both enterprise and consumer versions).
|
|
