Development Environments help to develop secure code it is a primary security goal in the control design. A security practitioner should be familiar with the essential elements of a software development environments and their security implications on protecting source code and assets. A security practitioner should understand how the source code, assets, and environment are managed and controlled as they move through the SDLC.
This section will describe key aspects of the software environment, then will describe how configuration management is an important aspect of secure coding, and then finally will explain how to secure source code repositories.
Security of the Software Environment
So far, the discussion of software development environments security has covered the SDLC, operations and maintenance, change management, and maturity models. This overview has demonstrated the impact and importance of each topic to software development environments security. Here, we discuss the security of the software environment.
There are a number of topics related to the security of the software environment. This section focuses on the security considerations with programming languages, secure use of open-source software, database management systems, and security considerations of deployment environments.
Programming Languages Security
When it comes to the security of programming languages, not all languages are created equal. Nor are the security skills of the software writers who use these languages. Security with respect to programming languages needs to consider both the language used and the skills capacity of those who use it.
There are various ways to evaluate these aspects of security in the use of a programming language. It is possible to collect metrics on the total number of vulnerabilities for applications written in various languages. Furthermore, the impact of developers’ security skills on the capability to reduce these vulnerabilities can be measured. The security vendor Veracode analyzed more than 1.5 trillion lines of code from hundreds of thousands of web and mobile applications and in 2015 published some remarkable key findings in their “State of Software Security Report” (http://intersog.com/blog/ programming-languages-vulnerabilities-2015/). Here are two salient points in the findings:
- Web scripting language-based applications have significantly more cross-site scripting and SQL injection vulnerabilities than Java and .NET-based applications. The choice of programming language has a bearing on OWASP Top Ten pass rates.
- Software development environments team e-learning demonstrated a 30 percent improvement in vulnerability fix rates over companies that did not provide software security training.
To determine a programming language’s security, it should be looked at from the perspectives of language design and developer fluency. Both of these topics are examined more closely in the next two sections. Regardless of the language that is used, a related concern is whether secure practices are followed in coding and configuring the software. Those topics are explored later in this chapter in the sections “Configuration Management as an Aspect of Secure Coding” and “Secure Coding Practices.”
Language Design
Software languages vary in the security of their design. Software languages are human artifacts created for different purposes. Some languages are designed to work with computer systems at a low level, accessing memory, hard disks, and networking. Other languages are designed for higher-level specific purposes such as rapid web development environments or logic programming. Because of the variety of reasons languages are created, the emphasis on the security of a language varies as well.
The base C language is a good example. As a system-level language, the C language is powerful in how it accesses computer system resources. However, this power comes with a security cost as the language is vulnerable to buffer overruns, null pointer errors, segmentation faults, and other memory-related errors. Because of the level of access the C language has to the computer system, security in the C language strongly depends upon the security knowledge and proficiency of the software writer.
Another language is the Personal Home Page (PHP) language. PHP is designed as a scripting language specifically for rapid development of database-driven web pages with quick and convenient database access. And, as its name implies, PHP is a language designed primarily by individual creators. PHP is written in C, so it can inherit the security vulnerabilities from an insecure implementation of its parent language. However, the security concerns that emerge in PHP are more oriented toward its purpose as a rapid data-driven web development language. These are mainly related to the OWASP Top Ten Most Critical Web Application Security Risks. Similar to the C language, security in PHP language strongly depends upon the security knowledge and proficiency of the software writer as well.
Contrasted with the previous two examples, the Ada language, a language designed for military, avionics, and real-time systems, was designed with an emphasis on safety and security. The safety and security required by the types of software programs in these domains set high standards for the Ada language.
Many of the design features of the Ada language support a secure software implementation. Ada encourages a modular program structure that supports security by minimizing defects through good design and encouraging reuse, readability, and maintainability.
This is an important aspect of Ada, since it is specifically designed to be the software language of large and complex systems. Systems that are large and complex need to be broken down into manageable sets of functionality that can be developed, tested, and verified independently by different teams and then integrated into the product system as a whole when ready for release.
Good software design is important in minimizing flaws that lead to security vulnerabilities. Also, correct use of language syntax minimizes defect-causing vulnerabilities and thus security vulnerabilities. The Ada language has syntax checking, which ensures that programs written in it are correct. Ada’s strong type checking detects and prevents common software errors such as mismatched types and range violations. These types of issues have significant safety and security consequences in systems with high consequences to compromise or failure. Furthermore, Ada has built-in detection and protection against buffer overflow, null pointers, and array access errors, which are typical areas that attackers seek to exploit in software programs.
Java is another language that is designed with security built in. The Java Virtual Machine has a security manager that checks the validity and security of the byte codes of Java programs prior to execution. It has mature security libraries that support necessary security capabilities such as authentication and authorization, cryptography, secure communication, public key infrastructure, and more. It also has many security frameworks that are designed to support secure program development environments in Java.
As you’ve seen from the discussion of these languages, there are a number of considerations when evaluating the security of a programming language. One consideration is the amount of access to the computer system resources that the language offers the software developer. Another is the extent to which security is designed into the language or is being imposed upon the software by secure coding practices, frameworks, testing, and verification. Further considerations include the design purpose of the language and whether it supports secure implementations. The following are different security aspects of a programming language that you should use to evaluate the security of a programming language:
- Syntax checking
- Safe typing
- Safe pointers
- Safe architecture
- Safe paradigm implementation (e.g., object-oriented, function-oriented)
- Safe object construction
- Memory management, garbage collection, invalid access protections
- Safe and managed error and exception handling
- Safe startup
- Safe communication
- Safe concurrency, deadlock detection, and resolution
- Security patterns and frameworks
- Secure execution environment (e.g., a security manager)
- Developers’ security expertise
Developer Fluency
Many of the security vulnerabilities in software programs can be avoided by improving a developer’s expertise in the limitations, capabilities, and secure usage of the languages they use. Educating software development environments teams on security significantly improves their vulnerability fix rate. The foundation of security quality is established in software developers knowing how to implement security in the language that is being used. Ultimately, it is the programmer and not the language they use who is responsible for the secure operation of their code. Make sure that your developers and engineers fully understand the security features, patterns, and frameworks of the programming languages they use to develop your software.
Open-Source Software (OSS)
Open-source software (OSS) is computer software whose source code has been made publicly available. Some OSS is completely in the public domain, meaning that anyone can change it and use it for any purpose. Other OSS comes with a license that limits to varying degrees the rights to change and distribute the software.
Ever since the early days of software development environments, programmers would share soft- ware to learn from each other, get work done, and advance the field of computing.
Academia still often collaborates in software development environments. Notable examples are Donald Knuth with the TeX typesetting system and Richard Stallman with the GNU operating system.
Several considerations of OSS include its provenance, benefits, community, and security concerns and approaches.
Software of Unknown Provenance
The concept of software of unknown provenance is a significant security concern that should be a priority consideration when selecting or using OSS. Software of unknown provenance describes software that has not been developed with a known software development methodology and thus has uncertain security. Some OSS projects can fall into this area of concern because of the open and voluntary contributions to the project’s soft- ware development environments. Be wary of OSS that does not follow a software development process. Be sure to verify that there is acceptable quality, feature, and security governance of open- source projects.
Benefits of Open-Source Software
Without OSS, we might not have the World Wide Web as it is today. Linux, Apache, PHP, and Java frameworks are a few technologies that enabled the Web to grow quickly. Being able to use OSS for free gave businesses an on-ramp to doing e-commerce on the Web and provided software engineers with opportunities in the marketplace. Businesses offered models of support for OSS, and the open-source projects continuously responded to pressures to improve. Overall, the accessibility and free functionality made OSS a popular and attractive choice as a foundation on which to grow online business during the early days of the Web as well as today. OSS development environments has culminated in a range of possible benefits including flexibility, community, variety, licensing options, low cost, and potentially even security.
Flexibility
A common concern with proprietary software is “commercial lock-in.” Commercial lock-in is when a customer is locked in to having to use a vendor’s software because of a dependency on that software for critical parts of their business. Vendor lock-in means having to accept a software feature set dictated by the vendor and delivered on their schedule.
This is where OSS is different. A developer can modify OSS to meet their specific functional needs. Open the source, change the code, assure that it works and is safe and secure, and then use it.
Community
It is easy to recognize the knowledge, sharing, and passion of the community of people involved in OSS projects. Open-source contributors code for free. They need some specific functionality from software. They’re motivated to exercise or demonstrate their skills. Freedom and choice are fundamental to these individuals, and they want their software to be used. Documentation for OSS varies, since most developers focus on code instead of records. However, documentation and support do exist in forums, wikis, newsgroups, and chats for every popular open-source project.
Variety
The open-source phenomenon encourages participation and contribution as well as soft- ware consumption. A software developer can demonstrate their talents by contributing to open-source projects. Or they can create their own open-source project. There are many open-source projects that meet a wide variety of software needs. That is the benefit of an active, passionate, smart community of developers who are free to create software to solve many needs. The variety can be overwhelming, but services such as https://www .openhub.net/ can help you find the open-source software you need.
Licenses
A consideration to take seriously is the license option that comes with the OSS you choose. Make sure the license that covers the OSS you choose is one that fits with your software needs. Not all open-source licenses allow for the code they cover to be freely used within other software, regardless of commercial interest or lack of it. Consult with https://blog.codinghorror.com/pick-a-license-any-license/ for some food for thought concerning open-source licenses. Refer to https://opensource.org/licenses/ category for more information on specific licenses.
Cost
OSS is (mostly) free. The source code is free. The expertise to understand, modify, and use it is not. Many OSS products come with optional paid commercial support.
Security
Compared with commercial closed source code, whose bugs and vulnerabilities resolutions depend upon the resources of its parent organization, OSS has the eyes of the world on it to use it and hypothetically to report bugs, find vulnerabilities, improve upon it, and provide quality assurance. Yet, on the other hand, some believe that open-source transparency is a security paradox because the vulnerabilities are sometimes tragically overlooked and are open to the public.
To Trust the Herd or to Not Trust the Herd
A significant concern about OSS built by communities of developers is that access to the source code is also open to hackers and malicious users. Following this logic, one could assume that OSS is less secure than proprietary applications.
Beyond being exposed to the world, another security concern is that the open-source community may not be as focused to issue critical software patches as vulnerabilities emerge.
Some IT stakeholders distrust OSS because of its apparent lack of discipline and rapid change. These biases come from the early days of the open-source renaissance, when the coordinated efforts of the communities were immature. What was to become the most popular web server in the world, the Apache web server, was so named because it was “a patchy server.”
However, what can be viewed as weakness, in this case, can also be viewed as a strength. OSS is a significant part of most commercial IT infrastructures. Perhaps Kerckhoffs’s principle of transparency of an encryption system applies to the security of open-source software? Only if someone verifies the OSS for you.
Openness combined with the open-source value proposition has attracted commercial resources and support. A famous example of this is Red Hat Linux. Red Hat pioneered the open-source business model. Red Hat offers the Linux operating system for free, but it charges customers for maintenance, support, and installation. This business model makes sense for complicated OSS like Linux. As the open-source business model evolved, so did the depth of commercial involvement in the assurance and security of the software.
Your organization doesn’t have to rely upon commercial support, but expertise in the OSS you use is required to manage it. Regardless if you choose community, commercial, or organizational expertise, the best recommendation to ensure the safety and security of your OSS choices is to practice care, caution, and diligence in validating its security.
How to Secure Open-Source Software
The SANS Institute provides guidelines to secure OSS implementations in its “Security Concerns in Using Open Source Software for Enterprise Requirements”
(found at https://www.sans.org/reading-room/whitepapers/awareness/security-concerns-open-source-software-enterprise-requirements-1305).
- Security policy: A well-documented and comprehensive security policy is needed to guide an organization to realize the real benefits of the use of OSS. This security policy should provide guidelines on the selection, installation, security requirements, and maintenance of open-source. It should explain the scope and the basic guiding principle (a policy statement) and define the roles and responsibilities without any ambiguities. It is the basis of secure OSS use.
- Evaluation: All OSS should be thoroughly evaluated before its use by an organization. Don’t take the security assurances of the open-source project for granted. A technical evaluation of functionality, integration, and security should be done for verification. Seek out trusted sources to provide use and risk information to determine whether an open-source product falls within the acceptable risk of the Furthermore, conduct a CVE search against the OSS for security awareness.
- Avoid ad hoc installations: Do not allow administrators or users to download or install any unsanctioned OSS to critical All OSS to be installed and used in an enterprise environment should be sanctioned by the organization. Sanctioned OSS has been thoroughly evaluated and found to be acceptable for use. It has a formal installation process, and the organization actively manages it. Management of sanctioned open-source includes security and patch management.
- Download OSS only from trusted sites: Only choose reputable and trusted sites to download OSS. Trusted commercial entities that support OSS are good source.
- Prefer source code to binaries wherever possible: Most OSS comes in both source code and binary package formats. Trust the source code over the binaries. The binaries may not have been compiled by the source code. Verify the source code by verifying it against the MD5 checksums that should be pro- vided with it.
- Scan for vulnerabilities: It is important to conduct vulnerability scans on the OSS.
- Disable unwanted services: When preparing the OSS for any use, disable any unnecessary services or functionality options that are not required for it to satisfy your requirements. A rule of thumb, in this case, is to follow a “deny by default if not explicitly permitted” model.
- Have a defense-in-depth strategy: Always follow a defense-in-depth strategy to ensure the secure use of OSS. Taking a layered security approach not only protects the OSS from abuse but also protects your environment from the Make sure that you have a robust defense strategy in place.
- Install and forget model is very dangerous: OSS maintenance and operations must be audited periodically and conducted like any commercial software. The individuals in your organization’s open-source management program should subscribe to respected open-source security mailing lists. A patch management program should cover Software upgrades should be maintained current, provided they have been tested and verified to be safe for production use.
- Training and documentation are important: Training and education are essential for effective OSS security management. OSS often requires intensive technical expertise. An open-source training and education program should exist. It should be periodically audited and updated as
- Consider OSS in DR and BC plans: Your organization’s disaster recovery and business continuity plans should be updated to account for the dependency on the deployed open-source products. To successfully implement security and trust in the OSS your organization relies upon for its business, you should have an OSS program to ensure informed and secure selection, use, modification, and maintenance of software. This program would closely follow but extend software assurance guidelines to include the following:
- Requirements analysis, to establish the actual needs
- Acceptance criteria, for a formal evaluation to accept a selection
- Competitive analysis, to sort out the best selections from many
- Functional evaluations, to evaluate if software functionality satisfies needs
- Architectural evaluations, to ensure that the software satisfies necessary qualities such as scalability and integration
- Security evaluations, to gain information on the state of vulnerabilities and exposures of software, as well as availability of security patches
- Security testing, to conduct security tests to discover and become familiar with the risk profile of the OSS
- Secure procurement, to find a trustable source of software source code or binaries
- Commercial support, to find trustable and reputable commercial entities to provide support, product information, patches, upgrades, and so on
- Education, to educate information technology staff on OSS, from use, to code, to configuration, to security
