In simpler terms - A "Security Pattern" is a reusable design solution to a recurring "security-related" problem.
In a security design process, "Security Patterns" allows to represent a proven solution and helps architects and developers to communicate security knowledge using a common vocabulary and to identify risks that have been traditionally identified only by prototyping experience. The Security patterns can be an architectural solution or a defensive strategy illustrating how a security problem can be resolved.
Adopting Security patterns, depends upon your understanding of security domain, how you identify risks and vulnarabilities in your application design. Before choosing Security patterns, you must follow a Structured Security design methodology that includes risk analysis and trade-off analysis.
For more details, I would suggest you to read the "Free Sample Chapter" and "Patterns Catalog" downloadable from the book Web site.
If you have the book, Refer to Chapters 8 through 14, dedicated for "Security Patterns and Best Practices".
Bhaskar, Patterns are, in general, a proven software technique for capturing recurring problems and solving them in a standard way. They reduce time in the development cycle by providing the common terminology and implementation strategy that allows developers to coomunicate the problem and implement it in a reusable fashion. The patterns in the our book are focused on solving recurring security problems in J2EE and Web Services-based applications. You don't have to use them, but you will most likely end up trying to solve the same problems that they describe. If you choose not use them (or similiar industry patterns), you will just end up re-inventing the wheel. And that may be O.K., depending on your situation. If you want develop software quickly and have it maintained by others, using patterns is a good idea. If you need to sit around and justify time by reinventing solutions, using patterns is not a good idea.