The recipe for 'baking in' security in software systems
Connecting state and local government leaders
No matter what software or system development life cycle process is embraced, there are key security components that should be addressed early on to enable effective security.
For many years, security managers have espoused the mantra, “bake security in,” yet how to do so hasn't been particularly obvious. The reverse approach, “bolt security on (as an afterthought),” is easier to understand. Yet, it is often said to cost as much as 100 times more to add security after development than to plan for and include security from the start of the life cycle. This article, the first in a series on the Secure Software Life Cycle, explores what it means to bake security in from a macro perspective, covering the many essential security components. Follow-up articles will each explore an individual facet of the secure software life cycle in more depth.
Today, most organizations acknowledge that security is an important element in doing business. Awareness has been elevated with more public education on security issues such as identity theft. However, questions remain regarding how much security is enough, with much of the discussion driven by cost and business performance issues. These concerns often lead to shortcuts in the application of effective security within the life-cycle process rather than trying to force fit it later. Other reasons are lack of trained staff in security methods and procedures. No matter what software or system development life cycle (SDLC) process is embraced, there are key security components that should be addressed to enable effective security.
The traditional software development process can be implemented using a variety of well-documented models, including the Waterfall, Joint Application Development (JAD) and the Spiral or Iterative models. Let’s briefly review the characteristics of these common models.
The Waterfall model is the oldest and most familiar of the three. It is comprised of a series of sequential phases of life-cycle development, from project initiation and planning through system deployment. Based on individual implementation, organizations may segment the activity into as little as four phases and up to as many as seven.
Later SDLC models relaxed the perceived rigidity and forced sequencing of the Waterfall model, which also has heavy emphasis on documentation at each phase prior to proceeding to the next phase. Variations include more collaboration between end-users and developers through a series of Joint Application Development (JAD) sessions which were very popular in client-server environments in the early 1990s and use of a sequence of prototypes (or proofs-of-concept), prior to final product release, with various prototype iterations before final acceptance (Spiral or Iterative).
There was also a variation allowing for development and testing of software modules in parallel to shortened timelines for deliverables (Incremental) and combining aspects of all of the other methods with heavy emphasis on iterative prototyping, with each iteration introducing new functionality in each stage to minimize risk associated with large, complex applications.
No matter which model is employed, it is essential that the process allow for the integration of required security components. In today’s business environment characterized by wide Internet application deployment and aggressive competition for market share, flexibility in approaching SDLC activities is a necessity.
Regardless of the environmental challenge, common to all models are some basic activities which need to include security input. This article will focus on the ingredients required to bake security in to secure software life-cycle process rather than trying to append security components to the final product. Certainly in the current environment of virtualization and a move toward cloud computing, increased cyber attacks, and malware, this objective must be given high priority.
Baking security into software systems has a lot to do with who is involved in the SDLC process more than any other factor. Clear responsibility for overseeing this activity must be assigned to trained professionals knowledgeable in security methods and techniques. Common titles for such individuals include chief information officer (CIO), chief security officer (CSO), chief information security officer (CISO), and chief risk officer (CRO). A secure software life-cycle process should parallel an organization’s overarching business life-cycle process, overlapping the business process with specific security components and activities. The table below summarizes the major security elements that must be present in any SDLC process and how the two processes are paralleled.
1. Planning & Initiation
General |
Security |
General Project Description |
|
High level overview of desired functionality and business goals and objectives to be achieved |
High level security goals and objectives (Confidentiality, Integrity, Availability) based on business goals and objectives. |
Selection of project team members with assigned roles and responsibilities |
Assignment of security team members |
Training of project team |
Security team training |
Develop candidate system description |
Assign system categorization (high, medium, low) based on business impact |
2. Analysis & Requirements Development
General |
Security |
Collect end-user/stakeholder requirements |
Conduct initial risk assessment and select and document baseline security controls
Define any other security requirements in support of defined business requirements |
Derive/define application system functionality to be developed |
Define security functionality to be developed |
Maintain system documentation |
Ensure that security components are included in project documentation |
3. Design
General |
Security |
Define detailed system requirements |
Refine/update risk assessment Update security controls as needed |
Define system architecture (information model, database design, platform for development, etc.) |
Define security architecture |
Develop detailed system documentation |
Ensure that security requirements are included in documentation |
Update project documentation |
Assist with security documentation |
Update System Authorization preparation package |
Assist with providing security artifacts |
4. Implementation
General |
Security |
Develop software code |
Ensure that security code is included |
Develop prototype (if applicable) |
|
Conduct unit and integration testing |
Conduct/assist with security control testing |
Develop System Authorization Plan |
Assist as appropriate |
Assimilate Systems Authorization Package |
Assist as appropriate |
Install the operational system |
|
Submit system to Systems Authorization Process |
Perform security risk analysis Be available as security resource to address any security questions |
Achieve System Authorization |
Perform role in authorization process as defined by the organization (expert resource ) |
|
|
Deploy the system for business operation |
|
5. Maintenance
General |
Security |
Establish Continuous Monitoring Capability |
Establish Continuous Monitoring Capability for security components |
Perform Configuration Management & Change Control functions (requirement revisions, platform changes, corrections reflecting policy changes, etc.) |
Participate in Configuration Management & Change Control discussions with specific focus on security control requirements and any necessary updates/revisions |
Update/Revise system functionality as required |
Update/revise security controls as required |
Perform system re-authorization as required |
Perform role in authorization as defined by the organization (expert resource) |
6. Disposal
General |
Security |
Develop disposal strategy/plan |
Assess disposal plan for need to: · Sanitize media · Preserve information · Retain disposition records Submit disposal requirements to responsible official |
Sunset the system |
|
Dispose of Hardware/Software |
|
It has been six years since the National Strategy to Secure Cyberspace was published, citing a “critical area of national exposure” as “the many flaws that exist in critical infrastructure due to software vulnerabilities” and the need to reduce and remediate those vulnerabilities. The Homeland Security Department’s “Build Security In” initiative emphasizes the fact that software security is fundamentally a software engineering problem and needs to be addressed in a systematic manner. Key to this principle is building security in to software in every phase of development. This must be addressed throughout the SDLC. This initiative is based on the concept of community collaboration throughout the SDLC to achieve a high degree of software assurance.
Progress toward secure software has not been rapid, direct or orderly. Rush to market and short-term cost considerations continue to hinder secure software development. However, as mentioned, there is now a clearer understanding of both the software life cycle and where and how security needs to fit into the different phases. Recent discussions of the security life cycle have included the concept of control gates which are critical decision points in each phase of the SDLC, points at which decisions or evaluations regarding project status are made. This subject will be further explored in an upcoming article in this continuing series. Other articles in the series will cover security architecture and security standards, the supply chain influence on software development, barriers to secure software development and the people factor.
NEXT STORY: TechGuard announces new security appliances