Chapter 8. The Alchemy of Security DesignMethodology, Patterns, and Reality Checks
| Topics in This Chapter
In a typical application development environment, architects and developers share similar experiences. They deploy business applications in a highly compressed time framemaking the applications work, testing the functionality at all levels, ensuring that they meet expected system performance or service levels, and wrapping the applications with an attractive client presentation and user documentation. Ensuring the security of the application at all levels has usually been considered at the last phase of the development process. If this is your company's current application development process, then you are not alone. End-to-end security should be adopted and accomplished as part of the early application design and development process. It should not be addressed at the end of the deployment phase or even considered just before the system testing in a pre-production environment. If you wait to consider security at either of these points, your options for reactive or post-mortem security fixes are very limited. And it is important to note the fact that there is no rollback for an application security breach. In an enterprise application development life-cycle process, different architects may have different security architecture design perspectives for the same set of security requirements. Some assume that they can secure applications with infrastructure security protection (for example, firewall policy and proxy topology). Some would prefer to secure applications using a specific-vendor security framework and infrastructure solutions that are categorized as best-practice solutions for application security. Nevertheless, what was considered secure application design may appear to be insecure if someone discovers a loophole in the application that the security architects have overlooked in the early design stage. It would be challenging to create a quality application security design that is repeatable yet reliable, so that architects could ensure all aspects of application security are considered during the early design stage in a structured manner. In addition to that, there are industry best-practices for applying security that need to be put in place before the application design process. It is always accepted as a good practice to proactively check and verify the security design for risks, trade-offs, security policies, proactive defensive strategies, and reality checks upon completion of the application design phase. After production deployment, it is also important to adopt reactive security measures and defensive strategies to ensure service continuity and recovery in case of a security breach or malicious attack. These help in identifying and thwarting security-related threats and vulnerabilities in all facets of the application development life-cycle process, from use-cases to components, from components to prototypes, from prototypes to final implementation, from implementation to production deployment, and until retirement. With such a detailed verification process, architects and developers can reduce critical security risks within the software development life cycle and prior to production deployment. This mandates a security design methodology that provides a systematic approach and a well-defined process. This chapter will discuss the prescription for a robust security architecture design, which is the alchemy of securing business applications end-to-end at all levels. In particular, it will cover the rationale for adopting a security methodology, the process steps of security methodology, and how to create and use security patterns within that methodology. It will also look at how and why to do a security assessment as well as adopting a security framework. |
EAN: 2147483647
Pages: 204