The news regularly has stories of security breaches on websites. Having worked with identity security for years, I have seen a lot of mistakes made that are really easy to avoid simply by making security an essential part of the planning process. Two things to consider in the security of the site are how you are going to store and secure the identities, and how the security model will be built and enforced consistently on the site.
Use a solid LDAP directory
Let's first tackle the identity store. This is the backend that will hold all the identity information on users of your site. Think about when you log into say Amazon, or Google, or your companies internal social media site. The website needs to know about you, and every other users. It will need to store user name and password at the very least. Often you will want to store mailing address and email address, maybe a phone number. For the company site you might store the employees department, their employee number, the managers name, and what location they work. All of this is stored in the directory. Often when I read of security breaches the cause was because of a SQL database breach. If you use an SQL database then you need to build all the security around the database from scratch.
There is a better solution than using a basic SQL database. There are directory products that are designed from the ground up to be secure identity stores. Some examples of these would include NetIQ eDirectory, OpenLDAP, and Microsoft Active Directory. Under the hood these are all databases. However, the structure of the database is designed specifically to store identities, and to easily set security rights to who can see what in the directory. And they have stood the test of time for being rock solid identity stores. Make sure you have a person versed in the particular directory product you decide to deploy. Like SQL, LDAP is a common language that is cross platform, this time specifically for access to identity directories. The directory will have a full suite of features for setting up security in the directory from who can access what information on different identities, to being able to have groups for people to be assigned to, and even how many user entries can be retrieved at one time. It also will have the ability to have multiple servers with the same information for automatic fail over in case of server issues.
Use a web security product to lock down the site
A lot of times web developers will write their own security on the site. They will write login pages, and use processes they write to enforce security. The challenge here is you have a person who's specialty is writing web pages trying to design a security infrastructure into that same site. In the process they have to constantly keep in mind all the different possible ways an attacker might breach the system and write programming to prevent it. The web designer needs to find all the possible holes in the site. The attacker only needs to find one way in.
The alternative is to use a program that is designed to protect the web site from outside of the website. Examples of this would be products like CA Siteminder, Oracle Access Manager, or NetIQ Access Manager. Using an access management solution moves the security workload out of the hands of web designers and into the hands of security engineers. The software is designed specifically to protect sites while at the same time making access as easy as possible for users. The software is designed to also give the ability for a single sign on experience in an enterprise so that a user can log into one website and subsequently access many other sites in the same organization.
When you are getting ready to deploy a new website you need to make sure to bring in your security engineers right up front to help with the design of the site. The structure of the site can significantly impact how easy it is to design the security model around it. It is much easier to secure a site if sections of the site are laid out in a specific way. There might be certain sections of the site which should only be accessed by a subset of the user population. If the pages of those sections are in their own subdirectory then it is very easy to design the policy to restrict that whole section of the website to a particular group or groups of users as listed in the LDAP directory. If those pages are scattered all over then it becomes much more difficult to secure.
So how does the access management software work? Well it sits in front of the actual website. When a person tries to get to the site then the AM software will intercept the request and evaluate the user trying to access it. The AM software will be responsible for requesting the credentials from the user and verifying them. Once they user is authenticated the AM software will let them in. That is the first step, authentication. Once the person is authenticated in the AM software could just let them in if they will have access everywhere. Otherwise the AM software will next take on the role of approving or denying authorization to the particular part of the system the user is trying to get to.
The main home page of the system typically will be available for all users of the system. So once a user is authenticated in they will simply be allowed to the site on the home page. They also will most likely be able to get to the help pages, the about pages, and the contact information pages. So there will be no need for authorization on those pages either. But there might be a section that is specifically for only managers. For that section you might create an LDAP group called managers. The AM product will then have a policy that will say only if you are a member of the managers group will you have access to this section of the website. Another section of the site might be limited to people in the finance and accounting departments. So the users could be in a group called finance, and the AM policy would be set to only allow users in the finance group to those pages.
As we look at these hypothetical examples you might start to see why good planning up front is important. If you can collect all the pages and code for a particular part of the site in the same space then as you create new pages all you have to do is put them in the same subdirectory and they will automatically be protected with the same protection as all the other pages. If you put all the pages in the same place, or spread them all over the site then you will have to specify each of the pages individually for the proper protection. As new pages are created the web designers would need to make sure to inform the access management administrators of the addition so that they can be granted the proper protection. The more difficult the security model is the more of a chance of creating holes that an attacker can breach. Complexity always leads to poor security.
Along with being the traffic cop over the websites of the organization, a solid access management software program will also give solid auditing features. In recent years monitoring access and being able to answer auditors questions has become more and more important. Also, if there is a suspected breach it is vital to know who did get in, and what they got access to. You need to be able to determine what information might have leaked out of the organization. And you need to be able to have the evidence to take care of the situation. You also need to know if someone is attempting to get to a place on the system they are not supposed to so you can respond appropriately.
Products like Siteminder, Oracle OAM, and NetIQ Access Manager will keep logs of all the authentications and authorizations that were approved, and where on the site they were allowed, listing who accessed what. They will also record any denied authentication or authorization attempts. There are even programs like NetIQ Sentinel that can monitor these logs and watch for suspicious activity. Obviously there will be times a person accidentally stumbles on the wrong page of a site and gets denied. However, if the log starts to show a flood of repeated authorization denials to a particular part of the site by the same user account, or a sudden increase in denials by a lot of accounts, then it is important to be notified of this and be able to react. So a program like Sentinel can monitor the logs and look for that suspicious activity. Then you can have rules in place for notification of the suspicious activity. You can set up for email alerts, pages, and even escalation if something is not dealt with in a timely manner.
It is important to also set up a process for storing those logs for an extended period of time. Some of the vendors will have add on products to deal with the logs over time. These products will parse the log files into some sort of database that can then be searched and reported on. Or it is often possible to have a script that would retrieve the logs and push them into a SQL database. Once there they can be easily searched and reported on. Now if you end up suspecting a breach by an employee you can go back and find proof where they were on the site. This will give you the solid evidence you need to deal with the situation and the user.
Some final notes on network design
When you are laying out the system there are a few things to consider in the design of the overall system. First is the placement of the LDAP directory. Typically you will not want your directory exposed to direct access by users. So the directory should be at least on an internal network segment behind a firewall. Typically the websites that are Internet facing will be in the DMZ, or possibly behind a proxy. There are several ways to set that part up. But the LDAP servers need to be behind that. It is not a bad idea to maybe even put the LDAP servers in their own network island behind a firewall inside the internal network. If you want users to access directory information they should use some sort of website that would offer that up. Often they will use the directory in their email program. But there could also be a protected website (yes using an AM product to protect it) that would present them with access to the directory. Identity information is very important to protect from access. The LDAP servers should also be set up to prevent wholesale extraction of data too. It is possible in most LDAP directories to set up servers so they won't return more than a particular number, say 100 entries, to a wildcard search. It is also possible to set up a timeout limit too. Think of all the important information being stored in the directory. This will help prevent your organization ending up on the news. Some people might have a need to get reports on the entire directory, and for that you can set up a single server in the cluster of servers that would allow that access. Again, limit access to that server to a very specific set of people.
Another thing to consider is the setup of the different parts of the AM solution. Many of those solutions have multiple servers or parts that make up the solution. Put only the parts that you need to into the DMZ. The rest of the solution should be on the internal network segment. The guiding rule should be least access. You want to make sure that the most critical parts of your infrastructure are better protected. So for example with Siteminder you will want the policy servers on the internal network while the web agents are of course on the web servers in the DMZ. You will want to limit access to any identity and access management system to the smallest group of people possible.
I am truly a geeks geek. I have worked in computers for over three decades. I have worked on mainframes, Unix systems, Linux before almost anyone knew what it was, and many other systems. I love computers, and love making them do things people think is impossible.