Risk, Architecture and Development in the SDLC

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. The effort should use security architecture, structure within the systems development lifecycle and a proper coding program and training (Figure 1).

Security Architecture

Security architecture can focus on the implementation of eight core security capabilities and architectural standards serving as a ‘minimum necessary’ prescribing when they should be implemented in a system:

·         Risk-based Cost Benefit Effectiveness

·         Business Enabling

·         Adding Value to Core Business

·         Empowering Customers

·         Protecting Relationship and Leveraging Trust

·         Sound Management and Assurance Framework

·         Governance

·         Compliance

Security 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:

•        Confidentiality of business information (e.g., system functions that could result in disclosure of data accessible to the system);

•        Integrity of business information (e.g., a management command that could be used to modify customer data);

•        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. You 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 SDLC

To 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:

•        Architecture and Design requirements for use during the architecture and design stage by systems architects.

•        Systems Development requirements for use during the systems development stage by systems development.

•        Assurance and Testing requirements for use during the various testing stages by systems developers and quality assurance analysts.

•        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. The process is not without its flaws but software development teams should understand how to optimally apply appropriate controls during the SDLC. These groups need to take full responsibility for the systems they create from a security and risk perspective.  

Writing Proper Code

Many 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.  

The 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.  

In 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. Training teaches key security features and common web security pitfalls developers make and how to build secure and reliable systems. Developers should review hands-on code examples that highlight issues and prescribe solutions customized for their business environment. The 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.

Summary

The 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’s 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’s brand and reputation, and improve compliance with internal policies and external standards.