Christchurch Polytechnic Institute of Technology Information Systems Acquisition, Development and Maintenance Security Standard

Transcription

1 Christchurch Polytechnic Institute of Technology Information Systems Acquisition, Development and Maintenance Security Standard Corporate Policies & Procedures Section 1: General Administration Document CPP121e Principles Information Communication Technology Division Security Policy Security Standard, aligned with Security Standards Guidelines and Procedures AS/NZS ISO/IEC 27001: 2006 for Information Security Management

2 Contents 1 INTRODUCTION SYSTEMS DEVELOPMENT LIFECYCLE SECURITY STANDARDS SDLC: Design Standards SDLC: Development Standards SDLC: Test Standards SDLC: Implementation and Deployment Standards ACQUISITION OF SOFTWARE Security Assessment Software Purchasing and Licensing CRYPTOGRAPHY, CONFIDENTALITY AND COPYRIGHT SECURITY STANDARD Crpytography ICT Confidentiality and Copyright Standard Information Systems Acquisition, Development and Maintenance Standard Page 2 of 15

3 Information Systems Acquisition, Development and Maintenance Security Standard Purpose: This security standard defines the recommended security practices for designing, building, testing and implementing software applications through the Software Development Lifecycle (SDLC) process. This applies to developing new software, customising software and developing software that accessed or presented on a website. This document sets the benchmark for developing secure code and provides a clear indication of the processes to follow from design to implementation. In addition, this security standard recommends the security measures to be considered when acquiring new packaged software. Authorised: Document Owner ICT Director Information Systems Manager Date of Issue: 15 March 2012 Review Date: November 2014 Version: 2.3 References: This document should be read in conjunction with the ICT Security Policy. In addition it should be read in conjunction with the following ICT Security Standards: 1. ICT Asset and Media Management Standard 2. Human Resources ICT Security Standard 3. Physical and Environmental Security Standard 4. Access Control Security Standard 5. Communications and Operations Management Standard Information Systems Acquisition, Development and Maintenance Standard Page 3 of 15

4 1 INTRODUCTION Building security into systems during their development is more cost-effective and secure than applying it afterwards. Sound disciplines are required throughout the software development lifecycle process to ensure that information security is addressed at each stage. The principles of secure software development can also be applied when acquiring new packaged software to evaluate if third party suppliers apply appropriate security measures. Cryptography is a security control to protect the confidentiality and integrity of information and can be used to confirm the identity of the originator. This Security Standard recommends security measures that the Institution need to consider within the following software development processes: SDLC Design SDLC Development SDLC Testing SDLC Implementation Acquisition Cryptology Confidentiality and Copyright Standards used during the design stage of the SDLC. It is important that security is considered from the outset when designing a new software solution or web service. Standards used when developing software applications and web services including SharePoint. This includes defining the environments where software is developed and the tools used to develop new services. Standards used when testing new software or web services. Standards used when deploying new software into the Institution production environment. This includes a checklist to be followed. Standards for acquiring new software to minimise the introduction of new services that may compromise security Standards to be followed on cryptology and when to use cryptology, the benefits and best practices. Standards to safeguard information exchange and to prevent copyright infringements. Information Systems Acquisition, Development and Maintenance Standard Page 4 of 15

5 2 SYSTEMS DEVELOPMENT LIFECYCLE SECURITY STANDARDS The Systems Development Lifecycle (SDLC) is the process followed for developing and implementing software applications and includes the following stages: Design Stage Development Stage Test Stage Implementation and Deployment Stage Information Security needs to be considered across all stages of the SDLC to ensure appropriate protection for the information being collected, stored, transmitted or presented. It is important that security is considered from the outset when first designing new software or new services. Security standards for the SDLC are described within this document. 2.1 SDLC: Design Standards The objective of this stage is to ensure that security risks are considered when designing a software application, a new software service or a web service including those designed for SharePoint. Design Assessments The systems Design Stage should involve completing the following assessments: Data Flow Assessment to highlight the flow of information through the system to identify any potential security risks. This includes data inputs and connections to the system, transmission of data between the system components, storage of information, access to databases and other types of storage and connections to other systems or applications. In an agile development this may not be achievable up front but should be continually assessed and documented e.g. using a data flow diagram. Identification of specific security controls required by a particular activity at the Institute (for example linking an application to a human resources database may require a higher level of security control). Considering the ICT Security Policy and the requirements defined within this document. For example the password management standards. In addition, for new software development review the design principles checklist (shown below) and also prepare a design brief on the security architecture being used. This is to provide an explanation of any security measures being used; including details of the security risks, mitigating actions and any particular security risks not being addressed. Socialise the design brief with the Senior Solutions Architect and Information Systems Manager. Security Design Principles When designing a new software service the following Design Principles Checklist is to be used as the guiding principles for design. Information Systems Acquisition, Development and Maintenance Standard Page 5 of 15

6 Design Principles Checklist Ref Security Design Principles Considered in Design 1 Defence in Depth. Follow a design approach of 'defence in depth' with multiple layers of protection incorporated into the design. Defence in Depth methodology supports the use of multiple security measures in place rather than a single control (reliance on a single security control increases the security risk). The layers may be encrypted when transmitting data externally or may involve restricting transmission during an agreed period of time or to an identified internal address. 2 Design to leverage a minimum set of well-established development frameworks which implement good security frameworks. Consider more intensive security assessment and testing if a framework is not used. 3 Design with the assumption that all connections that originate from the Internet or other external sources (external companies, overseas connections, partners) are insecure and malicious. 4 Design with security defaults enabled. Reducing the 'out of the box' security controls in place will increase security risk. This is particularly important when using SharePoint or other web services that are accessed through the Internet. 5 Design to operate with least number of privileges; only the minimum account privileges are granted to a user or a process when accessing an application and not a high privileged account (like Windows Administrator, SA in SQL). 6 Only designed with dependence on components of externally acquired software, utilities or libraries which have been thoroughly assessed for security risks, and only with agreement by the Senior Solutions Architect or the Information Systems Manager. It is recommended that the information gathered in the design principles checklist is used as part of the design brief. Externally Acquired Software, Utilities and Libraries The design principles checklist (point 6) raises that designing with the use of externally acquired software, utilities and libraries requires careful analysis. The recommendation is that all components are evaluated and the security risks considered before deciding to use them within a design. Particular attention may be given to shareware and free or open source components. Note: This includes the many downloadable SharePoint utilities which can be added to a SharePoint library and provide useful services to CPIT staff without the need to develop new code. Component Evaluation The evaluation process should determine that good documentation and training material is available, technical support can be obtained, access rights meet the ICT Security Policy, updates are provided and the source is reputable. Information Systems Acquisition, Development and Maintenance Standard Page 6 of 15

7 Security Controls The Design Stage should include an assessment of the possible security controls that can be included within the design of the software application or service. It is important to consider these controls before finalising the software development. Security Controls to be considered are listed below in a table tick-box format which may be used when assessing the design process to be followed. Checklist of security controls to be considered when designing a new software service: Ref Security Control Applied 1 Information entered is validated to include: range checks, check digits, making any key fields mandatory and unaccepted key strokes enforced. 2 Information integrity is checked for accuracy, completeness, validity of information entered and if possible reconciled against authoritative information. 3 Detection of unauthorised or incorrect changes to information (use of checksum tools, reconciliation back to original source). 4 Protection of information being accidently overwritten, for example defining write-protected fields or locations. 5 Prevent internal information being disclosed to unauthorised individuals through application error messages or web server error messages. (For example errors not displaying the software used to develop the service). 6 Establish error logs, exception reports and event logs (automated as much as possible to reduce administration). 2.2 SDLC: Development Standards Developing software applications or customising software applications should follow industry best practice and consider security as part of the build process. This stage includes recommending standards on the: Application Build Process Standards Web Development Security Standards Development Environment Standards Application Build Process Standards The Applications Build Process, including coding and customisation, should be completed to follow best practice standards. Software builds should comply with good standards on system coding including: structured programming techniques, secure code and documenting code as advised within this standard. When coding systems, insecure process such as: using hard-coded passwords, insecure database lookups should be avoided. Externally acquired libraries or code examples are to be treated with caution and approval to use from the Senior Systems Architect. Information Systems Acquisition, Development and Maintenance Standard Page 7 of 15

8 Any defects or bugs are recorded within a defect log or similar system to record the issue and mitigating action. All software, new or customised, needs to be approved and signed-off before moving into the Test Stage. Development Environment Standards Software development should be performed in a secure environment. Ideally this environment will be isolated as much as possible from the live and testing environments and protected against unauthorised access. The objective is to provide a secure development environment to support software development and avoid the potential for disruption to the production business activities. Standards to be followed here are as follows: Software development environments should be separated from the production environment as much as possible to avoid the potential of a production service being impacted by malicious code or an inappropriate change. Software development computers should be suitably protected (for example using a firewall on a desktop computer and virus protection) dependent upon the level of confidentiality or sensitivity of the application being developed. Source code should be protected from unauthorised access and tampering using GIT or other industrystandard tools to check-in and check-out software applications. Why keep software development computers isolated? It is best practice to isolate computers that are used to develop software applications. This is to prevent malicious mobile code, for example executable code in the form of java applets, Microsoft Active X, JavaScript or VBScript that is untrusted, from being downloaded into the software development environment and then infecting production systems. Solutions include web filtering software on the desktop or a firewall or physical isolation. Web Development Security Standards Increased security risks are associated with the development of web-enabled applications like those that are used on www websites, extranets and SharePoint. External web servers hosting web applications should meet the following standards: Based on documented and approved application programming interfaces (API). Sensitive information in transit should be protected against disclosure by using encryption for example Secure Sockets Layer (SSL), and by using HTTP PUT operations rather than GET operations. Web Application sessions should be protected against session hijack or cloning by using SessionIDs that are randomly generated and by configuring the security parameters in cookies used to hold session information (session ID cookies are to be expired once an agreed parameter has been met or time period exceeded). Suppressing or modifying the server field in HTTP headers that identify the web server's brand and version. Ensuring that source code HTML, JavaScript and other client-side scripting languages do not contain unnecessary information. Server side executables and scripts (CGI, ISAPI) should not be configured to record actions performed. Information Systems Acquisition, Development and Maintenance Standard Page 8 of 15

9 2.3 SDLC: Test Standards Testing is a fundamental element of good practice in systems development. Planned well and performed correctly, it provides assurance that systems function as intended and reduces the likelihood of systems malfunctioning or introducing a security vulnerability. The following standards should be observed: A test environment should be created independently of the software development and live production environments. Hardware and Operating Systems and supporting software components, currently in use are to be used to test the software application. Similarly different web browsers in use are to be used to test web applications if the application is accessible through multiple browsers. Systems should be tested in accordance with predefined, documented test plans. Acceptance Testing should: o o o Include end users, students, academics or process owners Simulate the production environment Typically require sign-off to acknowledge the system performs as expected Security Acceptance Testing should: o o o o Be reviewed against the security controls agreed during design to assess compliance Assess the need for stress testing under high data loads or transactions Assess the need for sociability testing in deployment environment where appropriate. As necessary, and dependent upon the service being implemented, consider penetration testing either through third party engagements or software penetration tools, specifically designed running against abnormal datasets Dependent upon the software applications role and the agreed security risk, additional security reviews can include third parties to conduct code assessment reviews to detect vulnerabilities. Software development code should be sanitised prior to moving to production environments. The following checklist should be used before agreeing to move software to a production environment. Ref Sanitise Code Checklist Applied 1 Remove any authentication details used in the test environment 2 Remove any test accounts or passwords used 3 Remove any test organisational details or academic groups 4 Remove any test data 5 Follow appropriate Release and the Change Management Processes. 6 Design Stage (2.1) security standards have been followed Software development staff should be prevented from making unauthorised changes to live environments. Information Systems Acquisition, Development and Maintenance Standard Page 9 of 15

10 Information Systems Acquisition, Development and Maintenance Standard Page 10 of 15

11 2.4 SDLC: Implementation and Deployment Standards Before deploying software applications into a production environment, final checks are required to ensure that all security risks have been addressed. The objective is to ensure that only tested and approved versions of software are promoted into a live environment. The following check-list needs to be followed before agreeing to implement a software application. Implementation Check List: Ref Implementation Security Control Checklist Checked 1 Review that the security controls agreed in the Design have been undertaken or there is approval for not completing these steps.. 2 All necessary software patches or updates are applied before updating the software within a production environment. 3 All development issues/bugs have been closed off (defect logs are typically used to record issues). 4 Any legal requirements (like copyright/disclaimers) are added to the footer (this includes web pages). 5 Test data, test accounts or test messaging have been removed. 6 Any agreements with third parties have been finalised. 7 Appropriate Release and Change management processes have been followed. Information Systems Acquisition, Development and Maintenance Standard Page 11 of 15

12 3 ACQUISITION OF SOFTWARE Acquiring new software should be made with consideration to the ICT Security Policy, the security architecture in place and licensing. The objective is to ensure that any new software acquired from a third party does not compromise security, impact production services at the Institution and is legal. When acquiring software the following best practices are recommended: Software should be selected from a list of approved suppliers and if not, the supplier and software should be fully assessed for security compliance. Security requirements form part of any acceptance process like a Request For Information (RFI) or Request For Proposal (RFP). Software needs to be appropriately licensed for its intended use at CPIT. Perform a security check-list exercise to ascertain security awareness and any risks. 3.1 Security Assessment A security assessment check-list should be used to review supplier's security awareness, understand security requirements and recommended security practices. An assessment typically includes interviewing the supplier and asking them to reply to the questions you raise. Security Assessment Check-list: Ref Software Acquisition Security Checklist Checked 1 Assess ease of use to implement the solution, the greater the complexity the greater the increases in security risk. 2 Assess the level of privileges that are required to install and operate the software. The product should not require high privileged accounts to operate. 3 Identify interoperability and information flow to identify any security risks. 4 Review the security statement for the product and the recommended security settings. It is expected that the product will operate out of the box securely and that the company have made it clear what security controls have been followed. 5 Assess the product against the principle of defence in depth ; more than one security control in place the better the level of security. 6 Check that the product authenticates and is integrated to Active Directory or LDAP to minimise the need for a second authentication process. In addition, dependent upon the software product being purchased, it may be prudent to ask the supplier questions on the security controls within their product. The following are examples of questions that are recommended: Assess the supplier s experience, viability and support arrangements; review example SLA agreements to determine if they meet expectations. Information Systems Acquisition, Development and Maintenance Standard Page 12 of 15

13 Assess the supplier s ability to patch security issues and the process it will take to write and distribute updates. It is expected that a critical update will be available in hours, not days. Review supplier s history of identifying security issues and time to release patches. Assess the supplier s technical road-map to develop the application and support new systems (like upgrades to operating systems). Ask the same question to the supplier s technical staff (not sales staff) to see if you get the same response. 3.2 Software Purchasing and Licensing Software license agreements vary. Some licenses allow for use by one individual but can be installed on multiple computers. Other licenses stipulate a single machine. In addition, CPIT has software that is licensed for teaching purposes only and may not be used for any other purposes. Compliance is mandatory as defined within the ICT Policy. The following standards are to be observed: All software should be purchased through the ICT division who will record license agreement details and keep copies of the ICT media. All freeware software needs to be registered to CPIT and details passed to ICT for recording within the appropriate asset registers. Staff are to inform ICT when new software is under evaluation and follow the agreed practices within ICT for evaluating the software whilst noting the security assessment in section 3.1 Information Systems Acquisition, Development and Maintenance Standard Page 13 of 15

14 4 CRYPTOGRAPHY, CONFIDENTALITY AND COPYRIGHT SECURITY STANDARD Cryptography is an important aspect of information security. Cryptography can help enforce the confidentiality and integrity of information and provide a means to verify the individual or organisation. This section also recommends standards on copyright security for software. 4.1 Cryptography Encryption To protect the confidentiality of sensitive information encryption is to be used when necessary. The following standards are recommended: All internet facing services that contain restricted information. This includes: personal information, authentication details or require a higher degree of privacy should be accessed through a HTTPS connection. This also includes any financial services which involve payment across the internet or processing of payment details. Connections between applications that access private information or financial information, which are not physically or logically protected, are to be encrypted; this includes connections on a local area network. What is restricted information? Reference Data Governance Standards Note that restricted information is any data or material that if compromised could have a material adverse effect on Institute interests, the operations of the Institute or the privacy to which individuals are entitled. The appropriate encryption is to be reviewed each time a major software application is being developed. The current standard (December 2010) recommended is Advanced Encryption Standard (AES). Digital Signatures and Certificates Digital signatures protect the authenticity and integrity of the electronic information being transferred. The digital signature verifies who signed the document and whether the document has been altered. The key to digital signatures is maintaining the secrecy of the private key. The following standards apply: Access to encryption keys must be strictly limited to staff requiring access. Keys are not to be made available to third parties and remain the property of CPIT. If encryption keys are transmitted over the network, this is to be done securely. Hash Algorithm To maintain the integrity of information and to complete additional security checks against data manipulation, buffer overruns or tampering of information then Hash Algorithms can be included with the software development. 4.2 ICT Confidentiality and Copyright Standard The confidentiality of Institute information is a concern when the Internet presents the opportunity to freely contribute and share information. To safeguard CPIT information a copyright statement has been implemented. Information Systems Acquisition, Development and Maintenance Standard Page 14 of 15

15 The following information supplements the information within the CPIT copyright statement. Employees should not transmit sensitive Institute information through the Internet. If there is no alternative communication method available and all parties agree to information being transmitted through the Internet, then secure procedures are to be followed to confirm, receipt and encrypt contents. ICT can advise on a secure transmission process. Why worry about copyright? It is too easy to download copyrighted material from the Internet, on-line databases and other public sources without the regard that copying is unauthorised and a violation of copyright laws. This could lead to an embarrassing court action or internet access being restricted. Published Institute Internet content, on Internet web pages, collaboration extranets or download sites, should also be protected with a copyright notice. This is required to stipulate that the site is legally protected through copyright and that redistribution or reproduction is an illegal offense. This is the end of the Information Systems Acquisition, Development and Maintenance Security Standard. This standard is one of six standards that provide advice and guidance on the best practices to follow when using and accessing ICT services. The other standards are available on the Christchurch Polytechnic ICT intranet. Information Systems Acquisition, Development and Maintenance Standard Page 15 of 15