Hackers are getting better every day, the techniques and attacks are becoming much more coordinated and sophisticated. Attacks such as SQL Injection are known to destroy databases. Security and protection is more important than ever before.

Due to our N-Tier design and .NET language, we can provide one of the most secure systems available to Escalate customers. The inherent nature of our N-Tier design prevents many common, yet very dangerous, types of attacks, such as SQL Injection.

There are several ways to create and publish a web site with .NET, we have chosen a compiled design. All of the code except for the display part of the presentation layer is compiled, and thus more secure. If a hacker were able to obtain access to your web server, they wouldn’t have direct access to the source code.

Additionally, with our N-Tier approach, none of the presentation layer has direct access to the data layer, meaning the website does not talk directly to the data. It all must pass through the business logic. This provides a second layer of protection. Even with all this protection we don’t talk to your Escalate database, we talk to a replicated version. There is no connection to your Escalate database from the website. There are only a few instances we talk to Escalate and it is always through weborder, which has stood strong against attacks.

The business logic is also compiled and run through an obfuscator which protects against decompiling the code.

Due to the fact that the presentation layer does not have direct access to the data, for a hacker to gain access to your database they must have access to your internal network. With a properly setup network, this is unlikely, however if this does occur, the critical data such as passwords and credit card information are encrypted with 3DES, an unbroken algorithm. Additionally, even all the SQL stored procedures are encrypted.

If for example, a hacker were able to gain access to your internal network, also gain direct access to the database, also gain direct access to the business logic files and somehow was able to decompile the obfuscated code, they still can’t obtain sensitive data as the encryption keys are stored within the system registry of the business logic server.

In all, it would be extremely difficult for someone to get a hold of your sensitive information plus you are much more protected against many common yet very destructive attacks.

Also, in regards to the management console, it itself has a large amount of security as it contains some non-sensitive customer information. For a user to even see the login page they must be coming from an approved IP Block, which is controlled from within the management console. They must have valid login credentials. Additionally, there is a CAPTCHA to ensure that no bots are trying to crack the system. All admin credentials are also encrypted with the 3DES algorithm. For security purposes the usernames and password of the admin accounts are never displayed, if a user forgets their login credentials, they can only be reset, never read. Lastly, the user accounts are restricted to page level access, for instance the marketing users would not have the ability to see administrative functionality, even if they knew the file name and typed it in manually, each page checks the credentials of the logged in user.

If requested, additional security can be added to the login page. We have code to lock the administrative account after x number of failed login attempts. This can disable the account only to be re-enabled by an administrator, or we can lock the account for x number of minutes.