SECURE SOFTWARE DEVELOPMENT POLICIES

 Software development methodologies have rarely considered security as a component of

design.
 By including software development within security policies, organizations can prevent adhoc
redevelopment, thus keeping their in-house development from creating security
vulnerabilities.

SOFTWARE DEVELOPMENT PROCESSES

If your organization has software development policies and procedures, the place where
information security policies fits into the software development process is in augmenting their
efforts and ensuring that security is considered during design and development.

1. Identifying Software Development Responsibilities

 Security policies for software development should identify where the responsibilities lie in
promoting secure development and deployment of software.
 Assignment of responsibilities can make people accountable for developing or acquiring
secure solutions.
 Policies in this area also should mandate that security requirements be identified prior to
development or the acquisition of software.

This can be written as follows:

All software development and acquisition requirements shall include security requirements
consistent with these policies. The author of the overall requirements shall be responsible for
ensuring that security requirements are specified.

Now that the policy is written to require security in development, some organizations feel that
adding a policy statement directed at the programmers is necessary. The following policy
statement can be used for that:

All programmers involved in development and maintenance shall subscribe to all policies,
standards, procedures, and other development conventions.

2. Establishing Software Development Policies

 Three basic rules that promote the development of secure software can be considered
fundamental rules of software development.
 By including them as part of the information security policy, you can create a new focus on
these rules.

Translating these rules into policy statements, we can say

No software development shall occur without formal specifications. These specifications shall
include requirements for security and privacy of the data being collected and processed.

All software shall verify and acknowledge user input, regardless of outcome.
All software shall check and verify boundaries of data transferred to and from blocks of memory
to prevent overwriting of critical data and programs.
The last two statements address the buffer overflow problem, which is perceived as the most
common problem in software security.

3. Access Controls in Software

 Other problems that affect the security of custom software are the trap doors or special access
controls developers give to themselves under the guise of debugging or being able to
maintain the software.
 These access paths are usually not documented and go unnoticed until something goes
wrong.
 Few more policy statements help prevent these problems and cover all access paths that will
bypass security regardless of the reason they were added.

These policy statements can include:

No software shall be installed or considered for installation that includes shortcuts, trapdoors,
or any path that may circumvent security.

No software shall be installed or considered for installation that includes special access
privileges for developers.

 The next policy statement should address who is responsible for access control and security.

Simply write a statement that requires software developers to comply with established
standards:

All access privileges and controls built into custom software shall conform to the standard
administrative controls as outlined by these policies and associated guidelines.

4. Other Policy Considerations

 Some organizations feel that additional policies are required in order to use the security
policies to further strengthen their software development efforts.

For example with respect to the programming language being used:

All software development shall use one programming language consistent across projects.

A policy statement that addressed reusability concerns can be similar to this:

All software development shall consider reusing components of other projects. Software
development shall consider reusability a secondary goal of the project.

The growth of open software is a cause of concern for some managers. For this concern a policy
statement that said

All software development shall only use mature development tools and techniques.
5. Authentication Design Rules
 Identification and authorization are fundamental security mechanisms to guard the front door
into the program.
A policy statement can include:

Identification and Authorization of custom developed software shall use and integrate the
mechanisms of the operating system, database, or supporting software system in its design and
deployment.

Other policies that concern with the handling of the password information include

Passwords shall not be sent via electronic mail without being encrypted.
Passwords shall not be stored in clear text on accessible storage devices.
Passwords shall never be a static value stored within the program (hard-coded).
Memory used for deciphering and checking passwords shall be cleared once processing is
completed.

TESTING AND DOCUMENTATION

 One of the most neglected areas of software development security policies is the area of
testing and documentation.
 Both are important components of software development, but they have security
implications.
 A comprehensive testing plan can help find a number of problems before they go into
production.
 Proper documentation can assist testers in understanding what is being tested.
 Therefore, these policies should start with the requirement for testing and documentation.

A simple statement can say

All custom development shall be tested and documented before being installed into the
production environment.

 It is important to note that this statement is establishing the requirement, not the type of
testing or format of the documentation.
 This is an exercise that should be included as part of the overall software policies and
procedures.

1. Generating Test Data

 Sometimes the test team extracts real data from the organization's database to create test data.
 The data may contain personal information that should not have been publicly disclosed.
 There should be a plan to safeguard the personal or proprietary information of clients.

A policy for this can be similar to the following:

Data used to test software shall be generated from production data to properly simulate real
situations. This data shall be sanitized to remove sensitive or proprietary information prior to its
use.
2. Testing and Acceptance
 When testing has successfully completed, the policies should mandate that a plan be created
to install the new software.
 It does not matter if the software is an upgrade or new development; the plan should include
notifying users, operating documentation, and a way to reverse the installation should
something go wrong.

This can be written in three short policy statements:

Software accepted from testing shall include a plan to install it into the production environment.
This plan shall include procedures for uninstalling the software should it become necessary.

Installation shall not occur without notifying users to the procedures and error-reporting
requirements.

Software accepted for installation shall not be installed without appropriate operating
documentation.

3. Documentation Requirements
 Documentation is necessary for understanding how to use the system and how it works.
 Along with the requirements, developers should document the design, each component, and
their interfaces.
 This will prevent the duplication of efforts as well as document the controls programmed into
the software that meet the security requirements.

The policy to express this desire can say

Software development procedures shall include user and technical documentation that describes
how the software works; how it is operated; its inputs and outputs; interfaces with the system
and other components; and the security controls it uses.

REVISION CONTROL AND CONFIGURATION MANAGEMENT

 One way to ensure the ability to uninstall versions of software is through revision control or
configuration management.
 The security impact of change management is, knowing the configuration of the system and
its components.
 By knowing what is supposed to be in the system and the network, the administrators can tell
if security has been violated and rogue programs have been installed on the system.

You can establish this program with the following statement:

A configuration management program shall be established to maintain the configuration of all

production systems, including operating systems, off-the-shelf software, and security controls.

1. Revision Control Request Procedures

 One of the key security aspects of revision control and configuration management is the
ability to track changes.
 The first step in creating these traces is to have a policy that mandates a formal change
control procedure for all production systems.

This policy provides for written requests to perform system changes that can include a review for
security:

Revision control and configuration management shall establish a formal change control
procedure for all production systems. These procedures shall include mechanisms for written
change requests, maintaining the sources of development software installed on production
systems, and a review of security controls.

2. Configuration Management and Security Fixes

 Installed software may have bugs that can be an inconvenience in operations or may have
security implications.
 Installing patches, even from a vendor, can lead to unpredicted results.

A policy to cover these situations can say

Configuration management shall have procedures in place to test and install security fixes from
developers and vendors.

3. Configuration Management and Maintenance

 A policy that would force programmers to port their patches to the program's source after
they patched the object deck( in a mainframe environment) can say

All maintenance on custom developed software shall be performed on the program's source and
not it’s associated binary.

4. Testing Before Installation

 One of the dangers of working in change management is allowing the installation of patching
software before it is tested.
 Policy should require the testing and accepting of these patches whether a vendor or the in-
house development staff supplies them.

A good generic policy statement could read

All software shall undergo testing and acceptance prior to using in a production environment.
This policy shall include vendor-supplied software and patches as well as those developed in-
house.

5. Installation Procedures
 Configuration management policies should include the requirement to have both installation
and the ability to recover from an installation.

A statement can read

Configuration management procedures shall include procedures to install and roll-back to a

previous version should problems occur.
THIRD-PARTY DEVELOPMENT
 Some organizations do not have the expertise necessary to do some custom software
development.
 The third-party development projects represent potential security hazards that could expose
the organization to problems.
 The policies developed for third-party development should be designed to protect the
organization.

1. Policy to Guarantee Integrity

 When an organization outsources its software development, there has to be a concern over
the integrity of the software that is the result of that development.
 The difference is that these policies are directed to the third party and the agreements
forming those relationships.

This policy can say

All agreements with third-party software developers shall include a statement of integrity. This
statement shall include assurances of no undocumented features and that the software developed
shall not include backdoors, trapdoors, or other mechanisms to circumvent security.

 In addition to ensuring that the software does what it is supposed to do, it should be able to
work with the security controls of the operating environment on which it will be installed.

To extend the integrity policy, a policy statement can be added that says

All third-party developed software shall comply with established information security standards.
This software shall be able to be integrated with the controls of operating system or management
software.

2. Restriction Commercial Distribution

 When an organization uses a third-party developer to create custom software, the third party
also might be selling your business processes to your competitors.
 There can be fewer restrictions on the redistribution of development as the organization
might have no control over the third party.

One way of writing the policy can be

Where possible, third parties developing software for the organization shall not sell or
redistribute this software. Documentation associated with this software shall not be distributed.

3. Escrow for Third-Party Software

 As the number of recent failures of Internet software companies has increased, your
organization may want to consider what would happen if the company that is developing
your web site goes out of business.
 In most cases, when these companies close their doors, obtaining any of their assets is
difficult.
 However, if your organization has the third party place copies of the software (including the
source) in escrow, your organization could either maintain the software using in-house
developers, or you could give this information to another third party to maintain.

The following policy statement can be written for this

All third-party development agreements shall include a provision to place a copy of the source
and executable programs into escrow. These provisions shall allow the organization to access
that escrow should the third party fail to maintain the software.

INTELLECTUAL PROPERTY ISSUES

 Regardless of who performs the development, the final result can be considered intellectual
property.
 This intellectual property contains the business process and other proprietary information as
to how the organization operates on a daily basis.
 These programs should be treated as valuable assets.
 In the context of information security, gaining knowledge of this intellectual property can
give an outsider a view of the internal workings of the organization.
 This knowledge can provide guides to actual or social engineering of the systems and the
people using the systems.
 The result could be electronic break-ins or other computer security problems that could be
masked by using this internal knowledge.
 Most organizations have an intellectual property policy that is separate from the information
security policies usually written by attorneys to protect intellectual property regardless of its
intended use.
 For those organizations without an intellectual property policy, it might be worth the
resources to ensure your organization creates one.
 Because these policies must comply with the appropriate laws, which can be complex, your
organization should employ an attorney whose specialty is intellectual property to help with
this endeavor.