Define Security Requirements

To define security requirements, first an organization must define its risk appetite. At what level does the risk introduced by a business decision outweigh its benefits? At what point is a control introduced too expensive or could hinder business growth? And if risk management requirements slow down business growth, is it still justified as it enables sustainability of the business? Security requirements do differ from organization to organization and from industry to industry. While a bank may choose to encrypt all customer-related data, it may be not cost effective for a wholesaler. While the investment in applying the control may be the same, the potential impact of a breach differs significantly. As you define security requirements, identify the “crown jewels” of your organization and how to protect them.

Applicability of controls are typically determined through an application risk assessment driven by the information processed, business criticality, and type of application (e.g., customer facing versus internal). This application risk assessment follows an established methodology (based on the security requirements) and should be completed at the beginning of each project, ensuring alignment of the requirements with business needs and application characteristics. Incorporating this application risk assessment early in the project planning phase is more effective and economical than adding security to already developed or acquired technologies.²

Establish Policies and Procedures: The Guiding Principles for Effective Cybersecurity Programs

The application security policies and procedures establish when and how the application risk assessment should be applied. They also specify the controls being applicable based on the security requirements identified during the risk assessment. Without appropriate policies in place, the adoption of leading cybersecurity practices is left to the good intentions of the individual team members. The application security policies and procedures typically also cover controls such as and limited to secure coding methodologies, cybersecurity reviews, quality gates, and impact analysis of application changes.

Rules typically have exceptions. There will be applications for which it is not feasible to implement all controls required by policy. The exception approval and risk acceptance process should enable transparency into the risk exposure, as well as the business case. Depending on the risk exposure sign-off should involve the right level of leadership and obtaining the appropriate sign-offs.³

Safety First: the Importance of Secure Engineering and Development Practices

As described previously, cybersecurity considerations should be incorporated tightly within the application life cycle. Organizations can achieve this by adopting secure engineering practices and enabling a security-focused mind-set in the development life cycle.

Secure engineering approaches are focused on cybersecurity by design, a concept that applies security to all of the layers of an information system’s design, from the business process to the technology platform. By taking an engineering approach to cybersecurity, analysis can be performed both on the system and within program modules to ensure design and implementation of the appropriate security controls.

Some of the leading practices within secure engineering include adding fail safe procedures to handle errors and maintain data integrity for critical failures and validation of the inputs to protect against commonly exploited vulnerabilities, such as cross-site scripting and Structured Query Language (SQL) injections. Secure engineering guidelines should also include effective code design practices, including the use of tools to examine code for security vulnerabilities (system flaw or weakness that can be exploited by an attacker) as well as peer code review.

A security-focused mind-set in the development and test environment is important as well. Historically, developers have enjoyed complete control over the code they write and the data used during development. Depending on the sensitivity and criticality of the information system, additional cybersecurity controls may be warranted. Organizations should consider the use of well-defined code repositories with version control and check-out processes to mitigate code defects. Data sets used in development and testing environment should be sanitized from any confidential data to prevent undue access by developers.⁴

Security and Acceptance Testing: Cybersecurity Leading Practices

Too often, organizations evaluating an application for acceptance, whether externally sourced or internally developed, focus solely on functional requirements. It is important that cybersecurity requirements be included in the process.

As systems are developed, security testing is conducted to verify that systems are complying with security requirements and producing outputs as expected and only as expected. Applications are reviewed (in a pre-production environment that closely replicates the production application environment) from the perspective of a malicious individual. The purpose is to determine whether vulnerabilities exist (that may not by detected through secure code reviews) within the application that a cybercriminal can leverage to gain unauthorized access to sensitive information and cause disruption to services.

Preparations include creation of a detailed schedule of activities and test inputs and expected outputs under a range of conditions, as well as development of documentation to capture test results. The security testing process is incomplete if not followed up by collaboration with development and architecture teams for risk classification and prioritization, remediation strategies, and verification of remediation effectiveness.

Independent cybersecurity testing by external experts may be conducted for critical systems. Testing should not be limited to in-house developed systems; third-party software providers should allow procuring organizations to test software or, at a minimum, provide evidence of independent testing. Note that if not included in the purchase contracts, suppliers will be reticent to agree to vulnerability testing of their proprietary code base by customers or independent third parties. The best time to address the need to test supplier provided software is during the procurement cycle and contract negotiations.

Testing, Testing, One, Two, Three: Protection of Test Data

While testing applications, it is important that the test data used emulates production data as closely as possible. One of the most common practices in testing information systems is to simply extract production data and load it in the test environment. However, organizations could face cybersecurity incidents in these test environments, leading to exposure of sensitive and confidential data. Many organizations have suffered tremendous losses of personally identifiable information (PII) and protected health information (PHI) due to a test environment lacking basic cybersecurity controls.

For critical and sensitive information systems, the same level of cybersecurity controls used in production need to be applied in the test environment. Organizations should also consider practices like obfuscation (masking of identifiable details) for the test data and additional controls like authentication, encryption and audit logging. Organizations should also consider the procedures for disposal and termination of testing environments upon completion of the process.⁵

Risk of Impact: Cybersecurity Change Control Considerations

A change to an application or system can negatively affect the availability, confidentiality or integrity of an information system. This is why change control, fundamentally an IT process, has become an important cybersecurity control.

Numerous organizations have faced operational outages, reputational damage, and financial losses due to poor change control procedures, including a lack of communication between stakeholders, lack of conducting business impact analysis, and making changes to production environments instead of to a staging environment and promoting the changes to production. Hence, it is recommended that organizations develop detailed change control policies and procedures beginning with the design phase of a project through maintenance and operations.

Leading change control practices include use of a formal review process that evaluates the change. The review process includes risk assessment and impact analysis of the existing information system’s cybersecurity controls. To compensate for changes that have unforeseen impacts, back out procedures to revert to the prechange state are strongly recommended.

Organizations can further reduce the risk of impact by having a staging or test environment that mirrors the production environment but is isolated in case the change has unforeseen outcomes. Finally, it is important that documentation of the information system be updated to reflect the change.

To Change or Not to Change, That Is the Question

Vulnerabilities as well as general IT operating risks are often introduced through the modification of packaged software. In this context, modification refers to changes to the software code itself rather than configuration settings made available by the software developer. For example, when a user uses a “rootkit” to modify the operating system on a mobile device, built-in security controls are bypassed, making the device and the information on it vulnerable to hackers.

It is recommended to restrict modifications to packaged software. However, for exceptions, organizations should consider the following aspects and assess the exception based on business needs and risk acceptance criteria. Modifying packaged software often makes the software more difficult to support by the organization and the vendor. It also may lead to instability or performance issues and may make it difficult to upgrade to future versions. Modifications to packaged software also warrant a high level of scrutiny and process adherence from a change control perspective.⁶

Secure Operations

Once a system or an application is up and running in production, a number of ongoing security activities should be done to maintain security features as per the requirements (e.g., certificate/key management, patch management). For more information on security operations, see Chapter 21.

Decommissioning a System: Nothing Left Behind

With continual technology evolution and breakthrough, information systems often become obsolete or are transferred to a different technology platform. It is imperative to follow an end-to-end disposal process to effectively decommission a system.

The starting point is to design a disposal or transition plan in compliance with legal regulations, government policies, and license agreements. The transition plan outlines the steps to preserve information and manage records. Archived information, whether content based, management, or operational, comes in handy not just for migration to a new system or future reactivation, but also for developing secure future systems. When archiving data, applicable laws and regulations requirements (e.g., retention period) should be addressed; organizations operating across multiple international locations should be particularly careful with various requirements.

Once the data are preserved, all of the old information system digital media can be sanitized and disposed. The system is shut down and discarded followed by security review of the closure. The sanitization and disposal process should consider the information confidentiality level to apply the appropriate sanitization techniques in consideration of the risks.

The index of archived information (location and retention attributes), media sanitization records, hardware and software disposal records, and system closure verification should be documented.⁷

In-House Developed Applications

While custom software development is typically under the domain of technology officers and cybersecurity functions, business executives also need to consider the associated security risks and understand the impact to the organization:

• When developing an application, the focus is on achieving the business goals and very often security is overlooked, (e.g., an application handling confidential information with no encryption and inadequate authentication). Misalignment between security needs and actual security features may lead to a breach.
• Developing complex applications with thousands of line of code and interconnected systems is a very error-prone activity; coding errors may result in application vulnerabilities and may not be detected if the testing only focuses on application business functionalities.

Detailed code reviews can be established to identify security weaknesses in the code through automated scanning tools and escalating to manual reviews for detailed inspection of issues.

It is beneficial to consider building secure development enablers, such as acquiring secure coding tools (e.g., static code scanning, vulnerability scanning tools developed by leading security institutes like SysAdmin, Audit, Network and Security [SANS] Institute, Community Emergency Response Team [CERT]).

Do not assume developers are security experts by default; it is important to provide regular training with a focus on secure code development and the security pitfalls of coding. These training sessions should focus on high-risk areas of weakness including, but not limited to, topics such as information leakage, input validation, and error handling.