Assessing security of Web services, part two |
 |
EXPERT RESPONSE FROM: Donald Flinn
|
|
|
| > |
QUESTION POSED ON: 16 June 2003
What would you recommend as a way for a company to assess whether or not its Web services were secure?
|
|
| > |
EXPERT RESPONSE
Click to view part one of this answer.
The second step is to determine what type of Web services access you will or are providing. In my last answer, I categorized Web services into three categories: intranet, extranet and Internet. In addition, I discussed the various types of security products and functionality available today. (Please refer to that answer for a more detailed explanation of these categories.) Once you have determined the type of Web services access you offer, match the asset risk categories of the different assets from step 1 with the type of access. If you have any combinations of high-risk assets and Internet access, this should raise a red flag. You should try to eliminate the instances of this combination type. If you can't eliminate them due to business reasons, severely limit the users who are allowed this combination, set up legal agreements with those customers or suppliers with specific responsibilities in the case of a security failure and assign the highest level of protection to these transactions.
You might find that most of your transactions fall into the medium risk category. If so you might want to further subdivide this category. In any case, medium risk, Internet accesses should be looked at very carefully and should use high security. You should also attempt to limit this combination, if feasible. The high-risk extranet and intranet combinations should be examined next, with the extranet taking a higher priority in your analysis. Lastly examine the low risk combinations. You might decide that some of these low risk combinations, e.g. low risk assets using your intranet, may not require any security.
Recommendation #3, the architecture of your security system, is an important aspect of your overall security and not necessarily specific to Web services. An essential principle in assessing the security architect is to assure that you have protection in depth. This means that you should have protection throughout your computer architecture as messages moves from the perimeter of your site, into the mid-tier and to the back office tier. First examine the protection at the perimeter of your site, which is usually handled by a Web Server. This tier should perform a course level of protection that will reject any obviously spurious requests and requests that do not meet the criteria of your higher-level combinations, e.g. it may be set to reject any Internet, high-risk requests. Then examine the mid-tier protection of your security system. Here the applications should verify the authentication evidence and perform detailed access control checks of the message request. Finally examine the application and databases' protection in the back office portion of your system. Here you want verification of authentication and additional fine-grained access control.
An important principal in all the above is to match the level of protection with the risk level that you have assigned to a particular type of transaction. In general, the higher the security, the higher the cost, therefore, be sure that the risk that you are protecting against matches the cost of protection.
Since space for each of my answers is limited and Web services security is a broad topic this answer has proffered general principals. I'll dig into specific details in my answers to future questions, as they become more narrowly defined. The way the questions have started coming in is very good as we are beginning with a general overview of Web services which will give the you a good basis for understanding the more detailed questions as they come in.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
