Project 4: System Development or Application Assurance Start Here It is critical that cybersecurity professionals be able to use all applicable systems, tools, and concepts to minimize risks to an org

The Software Environment

The software environment includes processes, languages, security features, and development models that together deliver security, flexibility, and functionality. Security is paramount in software environments, as it can assure the integrity of the software, ensure that the software performs as designed, and can audit and log software modifications.

Object-oriented components, processes, and systems are geared toward objects and data. "Object-oriented (OO) technology has emerged in recent years as the clear choice for developers of large, dynamic applications. OO technology allows developers to encapsulate data and operations in units called objects. Each object is independent of others, and groups of objects cooperate to solve specific problems" (Cobb & Shaw, 2000). Examples include object-oriented security, object-oriented security, and object-oriented programming.

Software development environments include open source and off-the-shelf. An open-source environment involves software development conducted collaboratively by multiple independent entities. While the rights to the resultant software may be owned by a single entity, the source code continues to be made available for editing through licenses. The benefits of open source include the potential for enhanced and more diverse creativity.

Security is a concern with open source; however, proponents of open source argue that with a diverse set of contributors, the likelihood of finding malicious code is increased in the open-source environment. Still, there is a strong open-source community comprised of experts and volunteers who advocate for open development and collaboration.

By contrast, off-the-shelf software is generally proprietary software that is developed, owned, and controlled by one entity, which also solely develops new features and tests for security. While configuration control is generally not at issue, cost, requirements, and security remain areas that must be carefully considered. Additionally, owners/developers of proprietary software are generally limited in the resources available to address bugs or security issues, potentially delaying the development of patches and increasing the potential for vulnerabilities to be exploited.

References

Cobb, M., & Shaw, K. (2000). Distributed object-oriented systems. http://www.scpe.org/index.php/scpe/article/view/175

Security Issues in Source Code

The security issues of source code depend on a number of factors, including the integrity of the processes used to develop the source code from a perspective of human practices as well as the development environment itself.

Source code is susceptible to many of the same threats that exist for networks and operating systems, including the use of malware to corrupt and/or exploit the source code. There are controls that can be used to minimize threats to source code security. Such controls include having sufficient backup procedures so that prior versions of code are retained, and separating environments to protect the source code by isolating its development.

Security controls that can be used for source code development include process isolation and memory protection, which segregate processes and storage for enhanced protection. Password protection techniques can be used to reduce the potential for the exploitation of passwords. Such techniques can include the requirements for the frequency of password changes, password length and composition, and layers of access with appropriate password controls.

Sandboxing, or isolating source code development to a stand-alone environment, protects both the development of the source code itself as well as the involvement of other network assets in any security issues. Ultimately, there are a number of adequate security controls for source code.

Software Development Methodologies

Many organizations engage in the software development process, from manufacturers of major software packages, to companies implementing commercial off-the-shelf software (COTS), to custom, in-house development.

To be successful, a company must use a standard software development methodology, especially in an environment where software security—injected in all phases of the project—is so important. These standard processes are traditionally called software development methodologies, or software development life cycles.

There are numerous methods used in developing software. Waterfall, rapid application development, joint application development, and extreme programming are some of the common methodologies used today. With software security concerns, even more methodologies are advancing in this arena. Nevertheless, within these major categories, there are variations that fit a company's needs.

Many life cycle models have been built upon the traditional waterfall model framework, while some newer models differ greatly. The waterfall model is extensively used in practice, particularly in the development of large enterprise software systems. The other models vary in implementation cost, end-user involvement, and project implementation time.

The rapid application development (RAD) model and the joint application development (JAD) model have similar approaches. JAD is mainly a methodology, where system users, analysts, designers, and software developers are working together to specify the components of the new system. They use many techniques, including meetings, workshops, and retreats to define and design the system. These techniques are highly structured based on best practices in JAD processes, and the group meetings can be held over extended periods.

Maturity Model

Maturity models are used to standardize development to ensure consistency. In cybersecurity, a software assurance maturity model helps organizations with the development and implementation of a software security strategy. This process involves an assessment of the organization's needs, resources, and risk tolerance as well as providing a benchmark against comparable organizations.

A maturity model has a set of structured levels to describe the reliability and sustainability of the outcomes of an organization's practices, behaviors, and processes. Thus, maturity models facilitate the assessment of an organization's processes and methods, promote consistency, and provide an independent review.

Capability Maturity Model: An Introduction

In addition to using international standards to evaluate their information technology (IT) products, organizations also follow international standards to manage and improve their own performance and capabilities. The Capability Maturity Model (CMM) comprises five levels through which each organization must progress to achieve optimum performance or capability when developing secure software (International Quality Management Systems, n.d.):

Level 1: Initial. Apply workforce practices without analyzing their impact.
Level 2: Managed. Get managers to take responsibility for managing and developing their employees.
Level 3: Defined. Develop workforce competencies and workgroups and align with business strategies.
Level 4: Predictable. Empower and integrate workforce competencies. Manage progress through a defined set of metrics.
Level 5: Optimizing. Continuously monitor and improve performance.

CMM is the benchmark for comparing the software development processes of two or more organizations.

Working Through Capability Maturity Model Levels

What follows is how a typical medium-sized company might strive to accomplish the CMM Level 5 certification.

Level 1: Initial

At this level, the organization has not started any formalized methodology. When it decides on a formalized methodology for developing secure software, such as CMM, it moves to the second level.

Level 2: Managed

At this level, the organization ramps up the training, working environment, and personnel needed to begin the secure software development life cycle. For example, the organization might initiate training on secure coding practices and training for auditors to show them how to document and evaluate information assets.

Managers then create working environments, in which breakout groups are asked to work on individual aspects of the formalized methodology. For example, an organization might create an auditing group, a secure coding group, a project management group, and departmental leadership groups.

Level 3: Defined

In this level, the organization further defines its methodology by breaking out its personnel into more focused and specific working groups, developing best practices and creating a culture in which the staff participates in the program to increase their investment in the outcome.

The secure coding group, for example, could be further divided into secure coding for databases, secure coding for web servers, and secure coding for network administrators.

The groups then develop best practices for how they will communicate among each other and share/report information, along with best practices for securely coding customer databases and web servers at the subgroup level.

Level 4: Predictable

At this level, the organization's processes are stable and established in ensuring secure coding.

Leaders mentor the staff, and the individual working groups—which now have a deep knowledge of the processes and in-depth frontline experience—are empowered to make their own decisions, such as deciding whether to use a different coding protocol on a customer database based on several small issues on the database.

Performance management is also put into place. The organization identifies a benchmark and establishes metrics to measure progress toward reaching that goal. These metrics are also used to monitor the progress of all teams in the organization.

Level 5: Optimizing

At this level, the organization finally optimizes its process, adapting it to new challenges and continuing to monitor and improve it regularly to ensure continued excellence.

Review

Of the following tasks, consider what level of the Capability Maturity Model (CMM) each would be performed by an organization.

monitor progress through established metrics
create best practices and workgroups
formalize a methodology to improve processes
organize the personnel needed to establish workgroups

Monitor Progress Through Established Metrics

The organization puts performance management policies in place that allow it to monitor progress at CMM Level 4.

Create Best Practices and Workgroups

At CMM Level 3, the organization further defines its methodology by developing best practices, breaking out personnel into more focused and specific working groups, and creating a culture in which the staff participates in the program to increase investment in the outcome.

Formalize a Methodology to Improve Processes

The organization starts to formalize a methodology to move to Level 2 during CMM Level 1.

Organize the Personnel Needed to Establish Workgroups

At CMM Level 2, the organization ramps up the training, working environment, and personnel needed to begin the secure software development life cycle.

References

International Quality Management Systems. (n.d.). People capability maturity model (PCMM). http://www.iqmsglobal.com/people_cmm.html

Integrated Product and Process Development (IPPD)

Integrated Product and Process Development (IPPD) is a management process that begins with product concept development and extends through the development and fielding of a product. The focus of IPPD is optimizing both the product as well as associated processes (e.g., manufacturing and maintenance) while at the same time meeting cost and performance targets.

Among the key principles of IPPD are (DoD, 1998; DRM Associates, 2016):

customer focus
concurrent development of products and processes
early and continuous life cycle planning
proactive identification and management of risk
maximum flexibility for optimization and use of contractor approaches
event-driven scheduling
multidisciplinary teamwork
empowerment
integrated management tools

IPPD is a widely accepted and used process including in the US Department of Defense. Advantages realized from the use of IPPD include a reduction in product delivery time, production costs, organizational risk, and increased focus on value to the customer (Management Study Guide, 2017).

References

Department of Defense (DoD). (1998, August). DoD integrated product and process development handbook. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwi_v4_O1OzRAhVFTCYKHfrEDrQQFggjMAI&url=http%3A%2F%2Fwww.
acq.osd.mil%2Fse%2Fdocs%2FDoD-IPPD-Handbook-Aug98.pdf&usg=AFQjCNHGyIdZBreb4VBgv9xpS5LsdaxNgw&bvm=bv.145822982,d.eWE

DRM Associates. (2016). Integrated product and process development key tenets. http://www.npd-solutions.com/ippdtenets.html

Management Study Guide. (2017). Integrated product and process development - meaning, advantages and key factors. http://www.managementstudyguide.com/integrated-product-and-process-development.htm

Software Development Methodologies

Libraries and Toolsets

Libraries and toolsets are important to develop and test software programs.

Software libraries are made up of suites of data and programming code that can be used to develop software programs and applications. The libraries are developed to help programmers build and execute software. An example of a library is a runtime library, which is used during the execution of a program to implement functions that are developed in a programming language.

Toolsets are collections of tools available for developing, compiling, and testing software. An example of a toolset can be found in the integrated development environment (IDE), where basic tools needed by developers to write and test software are consolidated.

Software Development Life Cycle

The software development life cycle (SDLC) defines the steps needed to develop and maintain software through its usefulness. This process is initiated during the software design phase and focuses on quality development standards that result in timely and cost-effective delivery against requirements.

Security analysis and testing is an important component of the development cycle and should be considered through every step of the SDLC, which includes the following phases: analysis, requirements document, design and prototype, implementation (coding), testing and release, and maintenance.

While SDLCs historically were focused on satisfying functional requirements through software development processes, the increase in cyberattacks has resulted in adding the integration of security into each phase of the SDLC.

System Development Life Cycle

System development life cycle (SDLC) is a multistep process used to develop, implement, and decommission information systems, to include both hardware and software components. The purpose of using an SDLC approach is to deliver systems that meet customer requirements within the projected cost and schedule parameters.

SDLC steps include:

planning
requirements
design
development
integration and testing
implementation
operations and maintenance
decommissioning

There are a number of different SDLC models that cater to different types of developments. Among the oldest models is the waterfall model, which is a structured model with phases that are followed sequentially. While this model is easy to understand and follow, it has limited flexibility, providing little opportunity to make changes once a phase is completed. In contrast, the agile model produces iterative releases which include product testing after each release. While this model relies significantly on interaction with customers, it is a flexible and realistic SDLC model.