Sam’s Thoughts

Enterprise Security – Part II – Validate the server

2009-11-17T13:02:00+00:00

Continued from previous blog Enterprise Security – Part I – Login Validation

Certificates are used for a variety of implementations to secure communication from any non intended third party. In this case we are discussing the most generic of the certificates commonly known – server based SSL (secure socket layer) certificate. The purpose of the certificate is to prove beyond doubt that the server is who we think it is. This kind of security is generally setup to work on a security port – usually tied to port 443 (note – it does not have to be) and supported by the browser as “https”; an extension to the standard http protocol.

When a request is initiated for a secure https based website, the website responds with a certificate signature which identifies who it is. The browsers by means of setup root certificate authority (the list of root security certificates is pretty limited), are able to verify the signature provided so we can be sure that the data that is passed from the client browser to the server is encrypted and not pry to any prying eyes.

Various aspects related to corporate root certificate authority, and secure communication based on SSL would be a good read.

Please review the series with :

Follow the next blog at Enterprise Security – Part III – Validate the client (with certs)

Enterprise Security – Part III – Validate the client (with certs)

2009-11-17T13:00:00+00:00

Continued from previous blog Enterprise Security – Part II – Validate the server

This setup is little rare to find. This is typically used in extra secure installations where the server application needs to verify the identity of the client browser who is authorized to access the application. This type of setup is generally limited to within the corporate boundary. Assume an example of a mutual fund sr. trader with access to initiate transactions in multi million dollars. In this case, in addition to login credentials based security, the company wants to ensure that this request comes from a corporate machine registered on the network which has limited applications controlled and managed per corporate standards and it is not a rogue laptop on the network.
The setup in this case is generally a explicit client certificate which is generated using corporate certificate management engine (it might as well be a certificate from Verisign, Thawte, or any other known root provider). This certificate is registered on the client machine and setup to provide that to a specific server based website. During initial requests from the client to the website the client will provide the certificate for validation for the server to validate who he says he is. The server in this case might also be setup to provide certificate to provide who he says he is. The client might be prompted for login credentials by various mechanisms identified in Part I and Part II (on this page). This explicit handshake and login credential validation ensures that the application is being used appropriately by the right party in the correct environment, with “almost” impossible probability for a third party to hack that communication channel.

Please review the series with :

Follow the next blog at Enterprise Security – Part IV – Web Application Security

Enterprise Security – Part I – Login Validation

2009-11-17T11:01:00+00:00

Continued from previous blog Enterprise Security

Most of you at some point in your career may have setup a local web server installation and probably published articles and pictures using web servers. However here we are talking about a more than the generic setup; we will describe a basic enterprise application centric security setup.

When coupled with a typical windows environment, IIS can offer a very powerful security setup. The following factors come down to NTFS permissions, directory security, form based security, SSL certificates, along with impersonation and services / port lockdown. IIS offers multiple types of security setup when it comes to web access. The following scenarios describe various security setup with the description of how they are likely setup and how they are used.

Login Validation: A client accessing the web site through HTTP (generally port 80 – can be different) can be offered “anonymous” access, similar to what most of us experience when we go to most http based web sites. When it is necessary to lock down the usage such that only registered users are able to access the content, directory security is enabled and anonymous access is disabled. You can only login if you enter valid “windows domain based login credentials”, and all content and documents within this website are secure from generic prying. This type of security setup is also called NTLM challenge response based login validation. This is commonly employed within inside and outside of corporate network boundaries.

Another form login validation is called form based security, a choice supported by using a .NET application with form based security. The way it works is when declared correctly in web.config IIS detects validation cookie with every request. In the absence of that cookie, IIS forces the user into a web form which explicitly prompts the user for credentials. The form when submitted generates a underlying windows ticket and ties it back to the secure cookie which is posted back in response to the user request. All further requests from the same client to the website now enjoy secure login and access to other resources available.

Please review the series with :

Follow the next blog at Enterprise Security – Part II – Validate the server

Enterprise Security

2009-03-27T10:52:00+00:00

Enterprise Application Security is indeed a broad topic subject to different levels of definition and interpretation, per system needs. Security needs for top secret Department of Defense projects would be lot different from the security required for an ecommerce application which intends to sell to the consumer. Having worked with different Enterprise Applications across a wide variety of industries, I prefer to look at security holistically with multiple perspectives. As a rule of thumb the more intense the security needs, the higher the cost of the entire implementation.

From an architecture layer perspective some of aspects to be considered are :

* User Access security – These include two factor and three factor access mechanisms driven by passwords, Biometrics, Single Sign On (SSO), Kerberos and various other mechanisms.
* Web Server security – HTTPS/SSL to encrypt communication between client and server. A mechanism without which most of today’s ecommerce based business on the internet would not exist to this advanced degree. The web server account itself should be a non-Admin level account setup to run within a boxed environment. Communication from the web server to the application server can be encrypted using SSL as needed. Security setup on Microsoft IIS is slightly different from Apache. The integrated support offered by IIS is difficult if not painful to achieve with Apache.
* Application Server security – The application server has to be running with a non-privileged non-admin account. The application servers have the capability to allow certain types of users based on group criteria. For example: IIS will allow us to define the domain users that are allowed for a certain site based on domain. IIS will allow us to setup impersonation accounts for anonymously access accounts, and so on. Usually the application server will validate the users, based on database/LDAP or other security models. The communication from the application to the database and/or LDAP and other systems can be encrypted using SSL on an as needed basis.
* Database security – Integrated login versus explicit login. The permission model can be based on windows groups and/or database groups. Complex web applications will provide granular application level security based on application level groups, and permissions per field type. Trusted / Integrated access support by Microsoft SQL Server is a addon but non generic implementation compared to other databases like Oracle, DB2 and others.
* OS Group level security – OS groups can be used at various levels nested through the web/application server level in conjunction with the file system group allocations in place.
* File system level security – Protecting the file system on the server is generally left to the level of generic access to everyone who can gain access to the machine. On Microsoft Windows (NT, 2000, 2003, 2008) machines this is NTFS access, while on Unix/Linux (HP UX, Solaris, Ubuntu, Debian, others) based infrastructure this is driven by rwx privileges per user, group and public. File system security access can be detrimental if the box is compromised. Explicit security and encryption can offer great level of protection at this level.
* Proprietary security implementations – Example the account required to modify the cacert for java based application server or the windows system level privilege requirement which is not even available to windows Administrator users, unless modified by local/Domain group policies through Microsoft Active Directory.

From an Attack Perspective:

* SQL injection
* Session Hijacking
* Denial of Service
* Social engineering to obtain fraudulent credentials
* Port scanning
* Firewalls
* Encryption over the wire

From a Physical perspective:

* Physically securing the location of your infrastructure is crucial to security.
* Storage encryption mechanisms to protect data if someone can get access to the data.
* Disaster Recovery procedures to quickly address issues related to physical outages in terms of location inaccessible due to massive power failure, fire, floods, and other hazards.

In the following weeks we shall dissect each aspect of security to dive deeper into understanding issues with today’s Enterprise Application Security.

Please review the series with :