CISSP online training: Software Development Security domain

Software development security organizations

Since software is the closest to the data that a company is responsible for protecting, there are many initiatives and efforts going on to increase the use of secure software development processes. There are also many groups and organizations that provide best practices in secure software development to help organizations achieve this protection.

The Web Application Security Consortium (WASC) is an organization that provides best practice security standards for the World Wide Web and the Web-based software that makes it up.

The Open Web Application Security Project (OWASP) is another organization that deals specifically with Web security issues. This group provides software development security guidelines, testing procedures and code review steps, and it maintains The OWASP Top Ten, a list of the greatest Web application security risks facing enterprises today.

The ISO/IEC 27034 standard provides best practices for secure software development that aligns with ISO/IEC's Information Security Management System model and ISO/IEC 27000 series. This standard provides an application security overview and concepts, organization normative framework, application security management process, application security validation and security guidance for specific applications.

The Department of Homeland Security has a Software Assurance Program that maintains an initiative called Build Security In, or BSI. This program provides best practices, tools, guidelines, rules, principles and other resources that software developers, architects and security practitioners can use to build security into every phase of software development.

MITRE has the Common Weakness Enumeration (CWE) standard initiative that maintains the top most-dangerous software errors. CWE provides a common language and taxonomy for software development security issues and details vulnerabilities found in programming code, product design and system architecture. NIST has mapped these CWEs with its National Vulnerability Database (NVD), which is the U.S. government repository of standards-based vulnerability management data.

Secure software development

Determining the appropriate level of security for a particular system is a difficult judgment call, and it depends on many factors, including the trust level of the operating environment, the security levels of the systems it will connect to, who will be using the system, the sensitivity of the data, how critical the functions are to the business and how costly it will be to apply optimal security measures. Understanding the processes and economics of system development is essential to comprehending why few systems used in production today can be considered sufficiently secure.

This section of the Secure Software Development domain covers how different environments demand different types of security, the importance of addressing failure states and the difficulty of balancing both security and functionality demands to meet business needs.

An overview of the history of system building and software development helps demonstrate why yesterday's approaches are no longer adequate in today's super-connected world, proving that the increasing complexity of modern environments and technology rules out a "one-size-fits-all" security approach.

The system development lifecycle

Every system has its own developmental lifecycle, which comprises the following phases: initiation, acquisition/development, implementation, operation/maintenance and disposal. Collectively these are referred to as the system development lifecycle (SDLC).

Each SDLC phase has specific goals and requirements; this domain focuses on these specific security goals and requirements and how they should be integrated into an SDLC model. Some of the SDLC models covered in this domain include:

• waterfall -- A sequential approach that requires each phase to complete before the next one can begin. Difficult to integrate changes, inflexible model.
• V-model -- This model emphasizes verification and validation at each phase and requires testing to take place throughout the project, not just at the end.
• Incremental -- Multiple development cycles are carried out on a piece of software throughout its development stages. Each phase provides a usable version of software.
• Spiral --This is an iterative approach that emphasizes risk analysis per iteration. It allows for customer feedback to be integrated through a flexible evolutionary approach.
• Rapid application development -- This model combines prototyping and iterative development procedures with the goal of accelerating the software development process.
• Agile -- In this model, iterative and incremental development processes that encourage team-based collaboration are used. Flexibility and adaptability are used instead of a strict process structure.

Balancing security with functionality

Open and distributed environments may be using both legacy and newer technology, as well as intranets and business partner extranets, all while maintaining marketing presence on the Internet for e-commerce purposes -- which in an entirety presents many security challenges. Yet strategies are being developed to better protect such systems by layering security controls at different technology levels. Being the last bastion of defense, security controls applied at the system and application level, however, should be as rigorous as possible

This section of the domain goes into the challenges and pressures software vendors face that commonly result in a lack of security built into the software products. Individuals preparing for the CISSP exam will gain insight into the decision-making process and the perils of relying too heavily on environment-based security devices and appliances rather than building the right level of security into a product from the start.

Most commercial applications have security controls built in, though only recently have vendors begun to set security on by default. This has forced users to make deliberate risk decisions to lower their security protection from the level the vendor recommends. While these approaches may prove annoying to the user at first, the increasing worldwide threat level necessitates not only an increased level of accountability from commercial vendors but also an increased level of awareness and responsibility on the part of the user.

Unfortunately, the economics of building secure software can be a tradeoff between the security and functionality of systems. While many in the industry voice concerns over the insecurity of today's software products, the customer requirement of functionality constantly overrides security needs. However, as attackers become more sophisticated in their methods, the industry as a whole is obligated to seek out new ways to reveal system vulnerabilities that result from uncommon conditions and to trap these threats so they won't be available for malicious use.

Securely built software programs depend on our ability to elevate the visibility and priority of security throughout each phase of the development process. As early as the project initiation phase, we can begin to formulate security goals based on business needs, liability risks and investment constraints. Throughout the requirements and design phase, we can systematically uncover hidden functional and architectural flaws that could compromise security. We can then apply inspection methods and automation during the construction and testing phase to root out coding flaws or failure conditions that are known to be vectors for security attacks. At every decision point, risk analysis should guide decision makers about the risks they will need to accept as a tradeoff for lower prices, faster time to market, increased functionality or improved usability. By using operational checklists for installation and administration, and by applying rigorous change control methods, software vendors can be sure that their products will meet both user needs and enterprise security standards now and in the future.

Vulnerability identification processes should be built into the application development process, including:

• Attack surface analysis: a process to identify and reduce the amount of code accessible to untrusted users.
• threat modeling: a systematic approach used to understand how different threats could be realized and how a successful compromise could take place.
• Static analysis: a debugging technique that is carried out by examining the code without executing the program and therefore is carried out before the program is compiled.
• Fuzzing: a technique used to discover flaws and vulnerabilities in software.

The capability maturity model integration (CMMI) is a process-improvement model that provides a pathway for incremental software development improvement. The model uses five maturity levels designated by the numbers 1 through 5, each representing the maturity level of the process quality and optimization: 1 = Initial, 2 = Managed, 3 = Defined, 4 = Quantitatively Managed, 5 = Optimizing.

The CMMI addresses the different phases of a software development lifecycle, including concept definition, requirements analysis, design, development, integration, installation, operations and maintenance, as well as what should happen in each phase. It can be used to evaluate security engineering practices and identify the ways to improve them. It can also be used by customers evaluating a software vendor. In the best of both worlds, software vendors would use the model to help improve their processes and customers would use the model to assess the vendors' practices.

Programming languages and distributed computing

After a brief overview of programming development, this domain of the CISSP centers on object-oriented programming, its encapsulation of code chunks as class objects and how those objects can be altered and reused. In creating application designs, the use of data by the proposed application is modeled and the data paths it will take through the application are analyzed. This domain is concerned about the atomicity of objects -- their cohesion and coupling properties -- as it will drive the ease with which they can be safely updated.

Software programming languages have evolved over time and are broken down into the following generations:

• Generation one: Machine language
• Generation two: Assembly language
• Generation three: High-level language
• Generation four: Very high-level language
• Generation five: Natural language

Each generation increases the capabilities of the programming languages that make it up, and each programming language has its own security issues that security professionals must be aware of.

This domain covers how data is imported and exported from the application. The usefulness of standards and technologies that ensure component communication (COM, DCOM), the seamless exchange of data between disparate systems (ORB, CORBA, ODBC, DDE), and the presentation or access to data outside the native application (OLE) are covered in this domain, as are the security issues surrounding the use of each.

This domain also covers service-oriented architectures (SOAs), which provide standardized access to the most needed services to many different applications at one time. Services within an SOA are usually provided through Web services, which allow Web-based communication to happen seamlessly using Web-based standards such as Simple Object Access Protocol (SOAP), HTTP, Web Services Description Language (WSDL), Universal Description, Discovery and Integration (UDDI), and Extensible Markup Language (XML).

Web security issues -- such as server-side includes, client-side validation, cross-site scripting and parameter validation -- are covered, along with countermeasures for each vulnerability type.

Database technology

Databases hold the data needed to conduct business, guide business strategies and prove business performance history. In this domain, database management software is covered, along with an overview of different types of database models. The database model defines the relationships between different data elements, dictates how data can be accessed, and defines acceptable operations, the type of integrity offered and how the data is organized. A model also provides a formal method of representing data in a conceptual form and delivers the necessary means of manipulating the data held within the database. Databases come in several types of models, including:

• Relational
• Hierarchical
• Network
• Object-oriented
• Object-relational

Relational databases are covered in depth, including how a schema is represented and used in the data dictionary, how it applies to security, how primary and foreign keys are related, how checkpoints and save points work, and how maintaining the integrity of a data set is essential to ensuring that no data falls outside the schema or the security controls built into the schema.

Data is useless if it can’t be accessed and used; applications need to be able to obtain and interact with the information stored in databases. They also need some type of interface and communication mechanism. This domain addresses some of these interface languages:

• Open Database Connectivity (ODBC)
• Object Linking and Embedding Database (OLE DB)
• ActiveX Data Objects (ADO)
• Java Database Connectivity (JDBC)

Database security issues are covered in this domain of the CISSP, including concurrency protection, Rollback capabilities, two-phase commits, checkpoints, and aggregation and inference protections. Secure and stable databases provide the ACID characteristics:

• Atomicity -- All changes to the database take effect or none do.
• Consistency -- Transaction must meet defined integrity constraints.
• Isolation -- No users or processes will be able to view a transaction until it completes properly.
• Durability -- When a transaction takes place, it is permanent.

Data warehouses (aggregators of disparate data sets) and data marts (copies of subsets of data warehouses) pose similar challenges, but the effort and cost that goes into these systems makes the metadata they yield very valuable to businesses, which warrants a correspondingly high level of protection.

Strategies for administering data systems for optimal security are also discussed. Topics include how to use security views to enforce security policies, content- and context-driven access control strategies, the challenges presented by aggregation and inference attacks, and the use of diversionary tactics (e.g., cell suppression, noise and perturbation).

Security threats and countermeasures

In this section of the CISSP, exam preparation includes an overview of the most common threat attacks affecting or engaging applications and systems as well as how they are executed. These include denial of service, timing attacks, viruses, worms, Trojan horses, rootkits and crimeware, among others.

Advanced systems employing artificial intelligence such as expert systems and artificial neural networks can aid in revealing connections between disparate pieces of information and recognizing anomalous patterns in network traffic or application behaviors that might signal an attack in progress.

CISSP® is a registered certification mark of the International Information Systems Security Certification Consortium, Inc., also known as (ISC)2.