Last time, we looked at a basic website design. Now it’s time to start digging into the details around what’s really being used behind the scenes. This time, we’ll focus on security aspects. When a user starts their browser and connects into the website, there are many layers of security that may be present to ensure only authorized users can access the data. The more valuable the data, the more steps required to ensure that this data is protected. Here is a typical setup for higher value content websites:
Each piece adds a different layer of security. All combined, they can act as a strong defense against unauthorized access of the information. The first two, are best done by a dedicated network engineer or network consulting services company that understands security implementations and is up to date on best practices and the latest procedures.
1) Firewalls are familiar to most. You setup firewalls in a static configuration to stop all traffic – unless to a service that you want available. For this, we use a Juniper SSG20 firewall:
http://www.juniper.net/us/en/products-services/security/ssg-series/ssg20/
2) Next, if you’re on the internet with valuable data, you should have a Intrusion detection system and Intrusion Prevention System. These detect abnormalities and protect the service by denying access from computers that act incorrectly. Perhaps the user fails login more than X times. Perhaps they’re fishing for a URL and doing iterative attempts to try and discover content. Perhaps they’re requesting a URL that’s a known buffer overflow attack? Juniper makes this unit which is a good starter:
http://www.juniper.net/us/en/products-services/security/idp-series/idp75/
3) From here, the application takes over security responsibility. It’s recommended to have an application server management consultant setup Single Sign On (SSO) due complexity. From there, an application programmer can handle the rest.
There’s typically a SSO that allows for authentication of the user. This authentication can take the form of a simple user/password. It can be extended to require SecureID cards with randomizing passwords. Or higher end retinal, face recognition, or fingerprint scanners may be used depending on the value of the data being presented.
4) After a person authenticates, they need to be authorized for the data they’re requesting. This is typically an LDAP lookup against Active Directory or some other.
5) Most companies stop here and allow the user full access to the SSL web service. However, one thing that’s common today: You no longer can trust the client computer that’s connecting into the site. It could be a company Desktop or Laptop and relatively safe. It could be a personal smart phone, iPad or other PDA, or worse: a public computer. You can no longer treat all computers the same.
For instance, what happens when your CEO logs into a kiosk at the airport because his computer broke. He/She needs to approve the latest acquisition plan of the XYZ Company. He/She can authenticate correctly…he’ll be authorized to see the content. What’s stopping a download of this critical information onto a public PC? Will any of this data be left in cache after he logs off? This is where Endpoint Integrity Checks are used.
Endpoint integrity are checks against the client PC. They can be as simple as: Did you run a virus scan in the past 30 days. More typical today is: will the data remain secure if loaded on the device. Is there an encrypted hard drive? Is there a BIOS password? Is the device a “sanctioned” platform?
6) SSL encryption of the transaction between the client and server. This is the last step of defense. Information passed between the two computers are encrypted in transit.
Security today is complex. And the cost of getting it wrong is harsh. During RSA 2011 discussions, the average cost for a single incident: $250-300k. Has HIPPA been compromised? Is Sarbanes–Oxley affected? Did company confidential information get disclosed? In the end, a better plan and execution up front can save money and aggravation in the end.
Subscribe to the blog to keep informed on network security, IT infrastructure, and other topics of interest to IT and engineering professionals.
1) Firewalls are familiar to most. You setup firewalls in a static configuration to stop all traffic – unless to a service that you want available. For this, we use a Juniper SSG20 firewall:
http://www.juniper.net/us/en/products-services/security/ssg-series/ssg20/
2) Next, if you’re on the internet with valuable data, you should have a Intrusion detection system and Intrusion Prevention System. These detect abnormalities and protect the service by denying access from computers that act incorrectly. Perhaps the user fails login more than X times. Perhaps they’re fishing for a URL and doing iterative attempts to try and discover content. Perhaps they’re requesting a URL that’s a known buffer overflow attack? Juniper makes this unit which is a good starter:
http://www.juniper.net/us/en/products-services/security/idp-series/idp75/
3) From here, the application takes over security responsibility. It’s recommended to have an application server management consultant setup Single Sign On (SSO) due complexity. From there, an application programmer can handle the rest.
There’s typically a SSO that allows for authentication of the user. This authentication can take the form of a simple user/password. It can be extended to require SecureID cards with randomizing passwords. Or higher end retinal, face recognition, or fingerprint scanners may be used depending on the value of the data being presented.
4) After a person authenticates, they need to be authorized for the data they’re requesting. This is typically an LDAP lookup against Active Directory or some other.
5) Most companies stop here and allow the user full access to the SSL web service. However, one thing that’s common today: You no longer can trust the client computer that’s connecting into the site. It could be a company Desktop or Laptop and relatively safe. It could be a personal smart phone, iPad or other PDA, or worse: a public computer. You can no longer treat all computers the same.
For instance, what happens when your CEO logs into a kiosk at the airport because his computer broke. He/She needs to approve the latest acquisition plan of the XYZ Company. He/She can authenticate correctly…he’ll be authorized to see the content. What’s stopping a download of this critical information onto a public PC? Will any of this data be left in cache after he logs off? This is where Endpoint Integrity Checks are used.
Endpoint integrity are checks against the client PC. They can be as simple as: Did you run a virus scan in the past 30 days. More typical today is: will the data remain secure if loaded on the device. Is there an encrypted hard drive? Is there a BIOS password? Is the device a “sanctioned” platform?
6) SSL encryption of the transaction between the client and server. This is the last step of defense. Information passed between the two computers are encrypted in transit.
Security today is complex. And the cost of getting it wrong is harsh. During RSA 2011 discussions, the average cost for a single incident: $250-300k. Has HIPPA been compromised? Is Sarbanes–Oxley affected? Did company confidential information get disclosed? In the end, a better plan and execution up front can save money and aggravation in the end.
Subscribe to the blog to keep informed on network security, IT infrastructure, and other topics of interest to IT and engineering professionals.
