All companies i depend upon business to business software applications to enhance operations, creating a broad range of risks in the process. These risks include security, availability, recoverability, performance, scalability, and compliance risks related to mission critical, internet facing systems. Many times, the primary cause of these risks is an absence of expertise and consideration of security and privacy during systems development. Previously unstructured implementations of risk mitigation measures in the systems development lifecycle lead to both over- and under-investment in development controls. Many companies claim to use a risk-based approach that incorporates cost-effective levels of risk mitigation commensurate with the corporations risk tolerance levels.\u00a0The effort should use security architecture, structure within the systems development lifecycle and a proper coding program and training (Figure 1).Security ArchitectureSecurity architecture can focus on the implementation of eight core security capabilities and architectural standards serving as a \u2018minimum necessary\u2019 prescribing when they should be implemented in a system:\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Risk-based Cost Benefit Effectiveness\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Business Enabling\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Adding Value to Core Business\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Empowering Customers\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Protecting Relationship and Leveraging Trust\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Sound Management and Assurance Framework\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Governance\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ComplianceSecurity architecture should prescribe when (e.g. what information to log to facilitate audit or when to encrypt data) and how to implement security in a product (e.g. what should be in an audit log or which cryptographic algorithm to use when performing encryption) so that the product is likely to be compatible with the most common industry security policies. The ability to select the proper security capability to implement starts with understanding system capabilities and the impact on the internal business environment. Especially critical are the system capabilities that have an impact on the following:\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Confidentiality of business information (e.g., system functions that could result in disclosure of data accessible to the system);\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Integrity of business information (e.g., a management command that could be used to modify customer data);\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Availability of business information (e.g., a system feature that could be used to make customer data or applications unavailable to the customer). Security Architecture should also prescribe confidentiality controls such as encryption, to be employed both at rest and in transit on any sensitive data (e.g. PII) handled by the system. Similarly, architecture requires integrity controls to be enforced on data, such as security configuration information, whose modification would create vulnerabilities in the environment. Security architecture requires specific serviceability capabilities to be implemented to enable secure service access to the system and to maintain the system with up-to-date security level (e.g. security patches).Architecture takes a wider more holistic approach to solving the business problem of security by ensuring that all of the components are specifically designed, procured, engineered, and managed to work together for the benefit of the business.\u00a0You should be able to easily answer the following questions:Do we have all of the components?Do these components work together?Do they form an integrated system?Does the system run smoothly?Are we assured that it is properly assembled?Is the system properly tuned?Do we operate the system correctly?Do we maintain the system?Security in the SDLCTo facilitate the implementation of the systems by the functional groups involved in a systems lifecycle, security architecture standards should be organized in alignment with the systems development lifecycle (SDLC) as follows: \u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Architecture and Design requirements for use during the architecture and design stage by systems architects. \u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Systems Development requirements for use during the systems development stage by systems development.\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Assurance and Testing requirements for use during the various testing stages by systems developers and quality assurance analysts.\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Serviceability requirements for use by systems architects, systems developers, and customer service ensuring that systems and processes enable secure serviceability.Security organizations need to create a repeatable and measurable process that enables systems development efforts to meet business demands for error-free and limited-vulnerability systems.\u00a0The process is not without its flaws but software development teams should understand how to optimally apply appropriate controls during the SDLC.\u00a0These groups need to take full responsibility for the systems they create from a security and risk perspective.\u00a0\u00a0 Writing Proper CodeMany firms use internally created programming patterns and practices cookbooks that serve as a library of defensive programming practices designed to assist developers with common challenges related to defect-free code. There are several common attack vectors and the defensive programming vectors that can be used to harden applications against potential vulnerabilities. Specifically, programming examples and references demonstrating both proper and poor programming practices as it relates to defensive programming should be provided. \u00a0The program should define examples of various attacks explaining how they exploit improper programming and what developers and quality assurance staff can do about it. The guide is not intended to be a complete summary of all possible variations of attacks and defenses as that is far beyond scope. Tables describing the most common attack and defensive strategies as well as an indication of which defenses work best for a given attack can be listed in a library. \u00a0In addition to the library of defensive programming practices, many firms either develop or contract for a series of awareness trainings then made available through the corporate intranet.\u00a0Training teaches key security features and common web security pitfalls developers make and how to build secure and reliable systems.\u00a0Developers should review hands-on code examples that highlight issues and prescribe solutions customized for their business environment.\u00a0The intent is to challenge all attendees with real world and past examples found their organizations code that is reinforced by practical and realistic code-level lab exercises. SummaryThe overall security architecture program should prescribe the use of industry standards across the SDLC: systems architecture & design, systems development and systems testing that reduce vulnerabilities and the risk of exploitation of vulnerabilities. It outlines a set of recommendations for systems development to prevent common security flaws in the area of systems design and software development.A basic software engineering truism is that fixing software defects earlier in the SDLC can save money in the long run. Development projects tend to slip on timetables, and end-of-cycle processes like quality testing are often abbreviated to keep projects on track. Conversely, when risk considerations and processes are integrated throughout the systems development methodology, organizations can realize significant improvements in their ability to design, develop, test, and maintain the integrity of systems, while at the same time improving the system\u2019s quality, time to market, reliability, and competitiveness. From a strategic perspective, a systems development methodology that addresses security helps normalize development and maintenance costs, decrease information risks, and minimize business disruption cost. Minimized risk also reduces business liability concerns, better protect your company\u2019s brand and reputation, and improve compliance with internal policies and external standards.