Originally posted by Jignesh Patel:
Hi Jignesh....my comments are inline <RN>,
I went through the sample chapter.
<RN> Thanks for reading through the chapter. As the chapter title speaks..it is all about introducing the reader to a structure design methodology, patterns-driven and best practices based security approaches and how to perform security assessments for Java/J2EE applications</RN>
I like the idea of explaining Security Patterns using the concept of
Security Wheel with Unified Process(UP).
The concept of Security Wheel represents the core security principles, which Java architect/developer must consider while designing an application. Some of those principles may not apply...but still it cannot be ignored..you consider them as Trade-offs.
We chose UML and UP, as they are considered as de-facto standard for representing application design models.
We did receive lot of positive feedback about both Security Wheel and Secure UP.
Is Signle Access Point differ then SSO?
Yes - both are different in terms of scope.
Single Access Point is a security pattern defined by Joseph Yoder and Jerry Barcalow (based on their security patterns research paper). It enforces a single point of access to a business service typically refers to a login page to an application.
SSO is an ability of an user to log in once to multiple applications that would ordinarily require their own separate logins. It allows an user to access disparate resources that can be accessed via centralized interface or portal. This is accomplished via creating an unique security token during authentication which is trusted by participating applications.. all subsequent requests are presented using the security token so that the user gains consistent user experience by doing single login access to multiple applications...all without reauthentication.
I don't understand PEP(Policy Enforcement Point), may be book explains
in more detail.
The policy enforcement point is a security entry point where all security functions are initiated ...such as authentication, authorization, audit functions based on the source of the request, transport protocol and incoming content. Policy Decision Point (PDP) is where all decisions are made to allow a request to be processed or not.
The books drills lot of details about PEP and PDP...in Chapter 7.
I don't know what do you mean by SQL Injections?
SQL Injections are all about exploiting data input in web applications...where a hacker breaks into the application by injecting malicious data or a condition that initiates a malformed SQL query via the JDBC statement executed on the underlying database.
We recommend the use of Intercepting Validator to thwart SQL and other malformed data injection attacks.
Secure Pipe pattern seems very usefull for web services security.
Alchemy of security Business Application is good to understand implementation flow.
<RN> Thanks for the comments </RN>
Description for implementing Security Policy in Check in item is interesting. Actually Check In item gives managerial aspect of implementing security.
<RN> Thanks again </RN>
For testing you suggested open source framework is prferable compare to
propriatory. But you haven't mentioned about any of open source framework can be used for white box testing of security.
<RN> We did recommend use of selected Opensource as well as commercial implementations for security testing in Chapter 14. We certainly don't want to give biased opinions when it comes to choosing software </RN>
[ January 13, 2006: Message edited by: Jignesh Patel ]
Originally posted by Vibha Jindal:
How are these patterns different from the J2EE patterns?
Are these patterns applicable to J2EE applications as well?
To support J2EE application development and address their core security requirements... Core Security Patterns builds on Core J2EE Patterns to ensure that security risks and vulnerabilties are identified and mitigated with appropriate Java based safeguards and countermeasures. These security patterns ensures end-to-end security including all J2EE Tiers and its core components.
I have 6 years experience in J2EE and would love to know the best practices in security as I've always felt that security is neglected in many applications.
Besides patterns and design strategies, the book identifies 101 Security best practices associated with J2EE applications and Web services.
The security best practices and pitfalls are intended for proactive security assessment of J2EE application design, implementation, deployment, testing and monitoring.
Are these patterns limited to Authentication or Authorization as well?
NO. The patterns looks into all possible weakest links of an application in terms of security risks and vulnerabilities and relate them with the fundamental security requirements such as...... Authentication, Authorization, Confidentiality, Integrity, Policy, Auditing, Logging, PKI, Availability, Compliance, Single sign-on, identity management, provisioning, Hardening & Minimization..etc.
Originally posted by John Hembree:
I'm not sure that you understood my question and quite possibly I didn't understand your answer.
I was looking for something along the lines of any information regarding the complete solution. Let's say I use this book and built the perfect application addressing every security issue within the realms of Java. The program was flawless, but then I installed the app on a server that I don't keep patched. It sits out in a DMZ or possibly inside my network without any firewall rules. The database server is sitting on the same box as the app. I don't know what else would be bad for me to do with my strong app but having compromised the other areas of my solution?
Do you have any generalized instructions of other steps I can take to secure my solution not just the application? Larger clients may have a security deartment that keeps all of things things in mind when deploying a solution. Is there anything that I can use within the book to guide me to other areas of security?
Originally posted by Scott Selikoff:
Are there any chapters that discuss or comment about proprietary solutions? I share your view that J2EE should be vendor independent, but I've been in situations where I had to use vendor solutions and I'm curious how they fit into the mold or if they are so different, that they don't fit anywhere at all.
Originally posted by Tina Coleman:
I was disappointed to not get to see a table of contents and index for the book out on Amazon. I know that's not likely the authors' doing, but passing along that feedback. Speaking as someone who's done a good bit of .NET programming of late, I wonder if the authors could speak to how much of the text is J2EE-specific, and how much would be more widely applicable. I expect that since this is a patterns book, it should be more widely applicable. Definitely interested in some of the various topics listed in the book blurbs.