You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 46 Next »

Table of Contents

Overview

To be most effective, information security must be integrated into the system lifecycle from system inception through system disposal. Regardless of the formal or informal lifecycle methodology employed, security can be incorporated into information systems acquisition, development and maintenance by implementing effective security practices in the following areas.

  • Security requirements for information systems
  • Security in development and support processes
  • Test data

Information systems security begins with incorporating security into the requirements process for any new application or system enhancement whether that application is purchased from a vendor or internally developed. Designing security requirements in systems is most effective at the early stages of system development. Similarly, security requirements are presented to the vendor during the requirements phase of a product purchase. Formal testing should be done to determine whether the product meets the required security specifications prior to purchasing the product or moving the application to production.

Security in development and support processes is an essential part of a comprehensive quality assurance and production control process, and would usually involve training and continuous oversight by the most experienced staff. Rules for system and software development should be developed. These rules should incorporate secure software development techniques such as user authentication, session control, logging, and data validation and sanitization. Unit, system, integration and regression testing should include testing of security requirements prior to deployment. Changes to the system as well as its operating environments should be managed, tested and approved. Support processes are closely related to ISO 12. Operations Security. As system maintenance occurs secure operational processes with regard to change control, separation of development, test and production environments as well as other operational controls provide many of the post implementation support processes and control.

System and acceptance testing usually requires Test data that is as close as possible to production data. Using production data for test data should be avoided unless mechanisms for removing personally identifiable information or other sensitive information in test data is developed.

#Top of page

Standards

ISO

NIST

COBIT

PCI DSS

2014 Cybersecurity Framework

HIPAA Security

27002:2013 Information Security Management
Chapter 14: System Acquisition, Development, and Maintenance

800-53: Recommended Security Controls for Federal Information
Systems and Organizations (specifically System and Services Acquistion-SA)
800-23: Guidelines to Federal Organizations on Security Assurance
and Acquisition/Use of Tested/Evaluated Products
800-64: Security Considerations in the System Development Life Cycle
800-144: Guidelines on Security and Privacy in Public Cloud Computing

APO01.06
APO07.06
APO13.01
APO13.02
BAI10.01
BAI10.02
BAI10.03
BAI10.05
DSS05.02
DSS06.06

Req 2
Req 3
Req 4
Req 6
Req 11

PR.DS-2
PR.DS-5
PR.IP-2
PR.IP-3
DE.CM-6
DE.DP-3

45 CFR 164.308(a)(5)
45 CFR 164.308(a)(1)
45 CFR 164.308(a)(8)

#Top of page

Getting Started

This topic is largely concerned with ensuring security is considered throughout the system development life cycle. Security risks and events occur throughout a system's lifetime. This is true whether the system is developed internally (build) or purchased for on-premise hosting or cloud implementation. It is important for information security to be involved in all phases of the systems development life cycle (planning, testing, implementation, operations, and maintenance). While system development methodologies are varied, most include these tasks in some form:

  • Planning and Requirements
  • Analysis and Design
  • Development
  • Test
  • Installation and implementation
  • Maintenance, including disposal

Security should be embedded throughout all phases. Microsoft has developed a Security Development Lifecycle that parallels the system development life cycle and can be used to assist in developing the role of security in each of the system lifecycle phases.

If a system is acquired or outsourced, a formal request for proposal should be developed that includes security requirements. Acceptance criteria should be defined, which will give assurances that security requirements are met. Indiana University's presentation from the 2010 Security Professionals Conference includes several ideas on how to Build Security into the RFP Process.

#Top of page

Security Requirements of Information Systems (ISO 14.1)

Objective: To ensure that security requirements are established as an integral part of the entire lifecycle of an information system.

The acquisition of a system or application often includes a Request for Proposals (RFP), which is a formal procurement process. During this process, security requirements need to be identified. Indiana University includes both a security review and a security questionnaire as part of the RFP process. Learn more about this effective practice by viewing Building Security into the RFP Process.

The University of Illinois Urbana-Champaign has developed a procurement process for evaluating whether an electronic service is considered to be low-risk, and potentially eligible for purchase using a P-Card. The criteria are included in Purchasing Software and Electronic Services with a P-Card.

Many institutions are looking to the cloud for information system solutions. Cloud Computing Security considerations are essential! Security professionals from EDUCAUSE member institutions published an excellent article, Cloud Services: Policy and Assessment, in the EDUCAUSE Review. Evaluating Cloud Risk for the Enterprise: A Shared Assessments Guide provides information to consider in evaluating the risk of moving applications to the cloud. Institutions need to perform due diligence to assess the security of cloud service providers. The Cloud Security Alliance has also published several resources to help assess security of cloud services. The Cloud Controls Matrix may prove particularly beneficial to those who are evaluating services prior to purchase.

George Mathew outlined security considerations for applications in the cloud at the 2011 Security Professionals conference. His Application Security in the Cloud session was recorded. Navigating the Clouds with an Enterprise IT Strategy, presented at the 2013 Security Professionals Conference, offers guidance from Furman University on creating a cloud security strategy. The University of Pennsylvania shared experience, lessons learned, and recommendations for creating a cloud policy, contracted solutions, and security assessments in Bring Your Own Cloud: Data management challenges in a click-through world, a presentation at the 2013 Security Professionals Conference.

As applications are developed for mobile computing, security requirements need to be included from the beginning. Developing a Campus Mobile Strategy: Guidelines, Tools, and Best Practices is an EDUCAUSE resource that offers an excellent strategy for mobile devices, including security considerations. The Hot Topic page on Mobile Device Security also contains numerous tips and links on how to secure mobile devices.

Applications often include data bases for backend processing. In the following case study, UC, Irvine provides a security checklist for data base administrators.
(lightbulb) Campus Case Study: Application Security for Database Administrators - UC, Irvine

An important aspect of overall information systems design involves the credentials that will be used to access the system. The InCommon Identity Assurance Profiles Bronze and Silver (IAP) document specifies requirements that Identity Provider Operators must meet in order to be eligible to include InCommon Identity Assurance Qualifiers in Identity Assertions that they offer to Service Providers. The IAP provides excellent security requirements for identity management systems. In particular, Section 4.2.3, Credential Technology specifies requirements for issuing and securing credentials. Further guidance involving credential technology can be found in NIST SP 800-63.

#Top of page

Security in Development and Support Processes (ISO 14.2)

Objective: To ensure that development lifecycle processes are established to maintain the security of information systems as the systems are designed, developed, tested, and maintained.

One of the security layers that can expose serious vulnerabilities is the application layer. Inventorying and securing all applications, software interfaces, or integration points that "touch" sensitive data is crucial in any organization that handles personal identity data, HIPAA, PCI, or any data that can lead to identifying confidential information. Unfortunately, this layer is subject to extensive variations and stretches across many technologies, human competencies, and organizational controls, practices, and standards. As such, it is difficult to secure and sustain, usually requiring departments to re-evaluate much of their software development, acquisition, and production control organization, staffing, and practices. Moreover, since applications are enhanced to adapt to changing business needs relatively often, even while the technology they depend on may also be changing, a consistent and "routinized" approach to maintaining their security must be adopted. Fortunately, there are many excellent resources to help organizations get started.

The Information Technology Infrastructure Library (ITIL) is one of the oldest and most mature frameworks for IT service management, and offers a wealth of best practice documents.

JIRA is a project tracking tool that is very useful for bug tracking and change management. Jira workflows can be customized and used to formalize testing procedures.

The following institutional case studies break down application security by the respective audience - management and architects, developers and QA staff, and the database administrator. Each area is instrumental in providing the comprehensive approach to ensure application layer security.
(lightbulb) Campus Case Study: Application Security for Management, Project Managers, and Architects - UC, Irvine
(lightbulb) Campus Case Study: Application Security for Developers and Quality Assurance Personnel - UC, Irvine

The need for highly skilled developers and support personnel cannot be emphasized enough. Security training is expensive, but can save the institution both dollars and reputation in the long run. The SysAdmin, Audit, Networking, and Security (SANS) EDU program is a partnership that helps to lower the cost of training for higher education security professionals. Relevant courses for software developers are listed in the SANS Secure Software Development Training Curriculum. System administrators will benefit from the SANS System Administration Training Curriculum.

The OWASP Top Ten is a baseline for addressing the most prevalent web development risks. Application developers should be well trained in coding techniques that control these risks, and software purchasers should require that products not be susceptible to them. At the 2013 Security Professionals Conference, the University of Pennsylvania presented a valuable methodology for securing web applications in Proven Strategies for Web Application Security.

#Top of page

Security of Test Data (ISO 14.3)

Objective: To ensure the protection of data used for testing.

Data used in testing environments such as quality assurance, test and development must be protected against unauthorized access. For example, test environments may be firewalled to restricted to campus systems. Accounts may be disabled so that only a subset of accounts can be used for testing. Copying data between production and test environment should be approved. Where possible data used for testing should not contain personally identifiable information. Guidelines for Data De-Identification or Anonymization should be followed to remove sensitive information or to modify it beyond recognition when used for testing purposes. If production data is used unchanged for testing, the data should be protected with the same level of controls used for the production system.

#Top of page

Resources

#Top of page


(question) Questions or comments? (info) Contact us.

(warning) Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).

  • No labels