Security Controls for Application Development and Maintenance

On a number of occasions, we have ask to help development teams to work out what are the right controls that should be included in their solution build and deployment activity. Theory/Doctrine provides a 'simple' path, pick your Framework to help understand, work out the risks ( from your Vulnerabilities and Threat) and then tailor to your activity to your needs, based on benefits.

While this IS the correct approach, implementation and adoption of a mature risk management approach can be often be out of step with the 'technical delivery', and the demand to 'do something' (familiar ?). We will often see either

• a mature Security approach with a developed strategy, underpinned with an enforced ISMS, but with little 'connection' or detailed understanding as to a set of technical controls that are needed in the development environment, or
• a 'technically' driven cyber approach, that promotes a set of technical baselines that implement standards or best practise ( CISA, NIST, CIS, OSWAP etc ). This is often done without detailed consideration of the benefits, or understanding the value of each control - but helps meet a compliance/assurance standard, and provides confidence that the solution would meet the 'Due Care' test if it was challenged.

These differing perspectives, and outcomes, often result from who is owning the cyber Risks ( the CRO, the CSO, the CISO or the CTO ).

Unfortunately Cyber Security is often seen as a 'techie' problem, that starts with buying something, and 'those guys in dev' turning it on. Experience shows that administrative controls (eg Training, vetting, reviews etc) are typically better value, and more prevalent - but again this comes down to assessing and managing the right risks with the right actions.

Securing Services, Solutions and Data

There are many different perspectives when it comes to securing application development, maintenance and operations in regulated, confidential or sensitive projects. And while we are discussing 'Applications', we are often actually trying to secure a Service or Solution, managing Data (either client, customer, citizen or corporate data), either 'At Rest', 'In Transit' or 'In Use'.

We will compare the popular frameworks (ISO27000, NIST, CIS frameworks), and how they relate to Application Development and Maintenance, and then look at some of the other key guidelines, including COBIT, CMMI, OSWAP and the NCSC, to help understand how they relate and support the securing of those Services.

Each standard, framework and guideline has a different perspective and view on how to understand, evaluate, manage and measure these risks. Some of these you may be familiar with, with many of these guides overlapping. This can lead to confusion on what is the best approach to use, how (or if) it can be adopted, and how each or any of them can be applied to your real-life systems and services.

Our context will be IT, Digital Services and Cloud delivery, focusing on how these frameworks apply to securing the Application Security during the Software Delivery Life-cycle.

Confidentiality, Integrity and Availability

Security controls look to reduce risks to Confidentiality, Integrity and Availability of services, solutions and their data. The vulnerabilities that will need to be mitigated will always depends on the scenario, the risks that are being managed, the risk tolerance. Each set of controls and/or framework attends to a particular context, and hence the right reference model will depend on circumstances and business need.

For example Citizen data in Health, Finance Data for Payments, and PII in Identification services all carry risks that are mitigated through the implementation of agreed similar controls, but often with a different framework, governance approach and set of standards. When it comes to Securing Applications, NIST (in the USA) and the NCSC( in the UK) both provide guidance to Public and private sector organisations, ( eg Application Development Guidance: Introduction ), although this guidance can be high level ( in the case of the NCSC guidance) or detailed but not tailored ( eg NIST Cybersecurity Framework ) . Public sector standards can add complementary guidance with specific standards, governance and controls (eg Service Design Assessments), Technical Assurance Gateway Review ) Private sector can also direct specific standards ( with their own sets of controls ), for example:

• Financial and Online payment services: governed by the industry PCI-DSS standard, that identifies the minimum levels of controls that should be in place in order to handle payment information.
• Health applications (in the US) are governed by the HIPAA regulations.
• NHS Digital has published the Data Security and Protection Toolkit
• Data Protection legislation in Europe and elsewhere provides guidance, standards and policy around citizen data management ( including controls on use, storage, recovery etc ).

In this guide we will look at how the ISO27000 standard, the NIST Controls Framework (800–53 & 218) and CIS Security Controls apply to securing application development and maintenance. We will then look some of the wider Governance and Assurance approaches, that can be used as part of a management framework ( rather than necessarily those that directly identify measurable controls ). CMMI, OSWAP, NCSC Policy, COBIT and ISO40215 all provide approaches that can help guide and secure development, delivery and operations, and be used as part of your Application Security approach.

What's the difference. ?

Each Framework has a different way of looking/managing your security risks, how to select, and then measure/manage those controls.

ISO/IEC 27001 is the international standard that outlines the security controls and procedures that an organisation should use to protect their sensitive data and assets. It focuses on risk management, defining the roles and responsibilities of personnel, and establishing policies and procedures for secure information handling. It looks more at the 'What' of the security control process, with less prescriptive (ie the How) on the actual controls that should be implemented.

NIST 800-53is a set of security controls developed by the US National Institute of Standards and Technology (NIST) for federal agencies to protect sensitive information systems from attack. It includes technical, physical, and procedural security measures such as system hardening, user authentication, and incident response. It can be considered more of the 'How' ( sometimes being compared an aligned to ISO27002 ). NIST 800-53b provides a clear list of controls that should be implemented to meet a threat level. The NIST Cyber Security Framework provides a simplified list of controls suitable for wider industry adoption. The NIST Cybersecurity Framework is a subset of NIST SP 800–53b, and provides a set of controls suitable for private sector organisations, similar to the NCSC's Cyber Essentials Framework

The CIS Security Controls Framework (V8) is a comprehensive set of industry best practices (controls) designed to help organisations protect their critical assets from cyber threats. It covers areas such as network security, patch management, asset inventory, user access control, and incident response. CIS Critical Security Controls Group 16 ( made up of 14 High Level processes) is specifically designed to outlined the steps recommended in Application Security.

All three frameworks are applicable to securing application development and maintenance. ISO/IEC 27001 focuses on protecting sensitive data, while NIST 800–53 provides technical guidance on how to secure systems from attack. The CIS Security Controls Framework provides general guidance on how to protect critical assets from cyber threats. While all should be considered, Its typically not appropriate to implement all controls from all frameworks at the same time ( as there remains great overlap). In each scenario, the organisation security operating model, its risk approach , the business threats and vulnerabilities should be used, to ensure the right framework is adopted that best aligns with the organisation and business requirement needs. There is much guidance on how each perspective relates to the other, so while the CIS Controls are very specific, they relate and map clearly to wider cyber controls under the ISO27000 framework. ( eg CIS Critical Security Controls v8 Mapping to NIST 800-53 Rev. 5 and CIS Controls v8 Mapping to ISO/IEC 27002:2022

ISO27000

The list below provides a summary of the key controls that are considered as part of the ISO27000 assurance possess (that relate to securing your Application life cycle). Typically these controls would be identified and managed as part of your wider ISMS/Security Risk process, so this list is provided here to help support any Design Assurance or planning activity, to ensure the right areas are considered to meet the (likely) risk and posture requirement.

1. Risk Assessment: Conduct a comprehensive risk assessment of the application development and maintenance process to identify potential security threats.
2. Data Protection: Implement data protection measures such as encryption, access control, secure storage, and secure transfer of data.
3. Security Controls: Implement security controls to ensure the integrity, availability, and confidentiality of data. This includes implementing firewalls, user authentication mechanisms, and monitoring tools.
4. Access Management: Establish a system that manages access to the development and maintenance environment. This includes setting up user roles and privileges as well as implementing authentication methods such as two-factor authentication for access to sensitive systems.
5. Change Management: Ensure that any changes made during the development and maintenance process are tracked and documented to maintain version control and prevent unauthorised changes from being made without proper authorisation.
6. Security Testing: Regularly perform security tests on the application to identify potential vulnerabilities or flaws in the system before they can be exploited by malicious third-parties or hackers.
7. Incident Response Plan: Establish an incident response plan for handling security incidents if they were to occur in the future. This should include steps for how to respond to incidents, how to mitigate them, and how to recover from them if necessary.

The ISO27000 set of guides is not typically available without purchasing, however you can find a number of resources that can help with implementation ( for example the https://www.iso27001security.com site collates open and freely available materials ). There is a a refinement of the ISO27K set of controls specifically supporting the application development lifecycle ( ISO/IEC 27034:2011+ ), although adoption has remained low.

NIST 800–53

NIST considers more closely the Application Development Life-cycle ( through a "DevOps" approach). Under its NIST 800–53b controls framework, it provides three levels of assurance (Low, Medium and High) that relate to the sensitivity of the data and the levels of protection that should be considered ( ie the suggested controls is banded into three different levels, so that they can be selected and adopted based on the sensitivity and threats to the solution/service. ). NIST also publishes the NIST Cybersecurity Framework, which an extract/presentation of the NIST SP 800–53b "Low" set of controls that are target at private sector business with a low risk profile.

NIST Controls can be adopted in isolation, when the wider organisation's security maturity is not as well developed. While NIST is often labelled as a framework for "US Federal Compliance" only, it is widely used in multi-jurisdictional organisations, and as a framework to support wider International accreditation. It is publicly available, and well supported, making it easy to consume. Like CIS Controls, NIST 800–53b can be also be mapped back to ISO27001 .

The following summary provides a useful checklist that can be utilised as part of any design assurance activity, providing confidence that cyber risks are being handled appropriately during development/delivery of applications handling sensitive information.

1. Requirement Analysis: Developing a comprehensive set of requirements for the application and its associated maintenance needs, that is based on a rigorous analysis of the environment, user needs and security objectives.
2. Design Review: Ensuring that an appropriate security design has been implemented in the application architecture, including reviewing system design diagrams and software code.
3. Development Environment: Establishing secure development environments which include strong access control measures, change management processes, automated testing mechanisms and other security controls.
4. Testing and Validation: Testing application code to ensure it meets security requirements and validating any changes to the application before they are deployed in production.
5. System Integration: Ensuring that the application is integrated with other systems securely and in compliance with best practices for system integration.
6. Deployment: Deploying the application in a secure manner, including configuring application settings, installing patches, performing vulnerability scans and other security checks prior to going live.
7. Maintenance: Monitoring the application regularly for any changes or vulnerabilities that can be exploited by attackers and responding quickly to address any issues that arise from such changes or vulnerabilities.

CIS Security Controls

The CIS Security Controls provide a set of best practice, measurable controls, for organisations to follow when creating and deploying applications. It includes guidelines on user authentication, authorisation control, secure coding practices, secure configuration management, patching and auditing. CIS also provides more detailed guidance on how to secure specific technologies such as web application firewalls and database encryption. Both sets of controls are important for ensuring the security of applications throughout their development life-cycle.

The CIS Controls are often selected/used due to their widespread support / adoption, and comprehensive nature. They are very ( by definition ) technical in nature, meaning that the ‘value’ of each and every control can be harder to relate to business need or value. They are useful where a “Due Care” and “Due Diligence” needs to be assured. That “comprehensiveness” can equally be daunting for teams that are resource challenged, where it is hard to clearly demonstrate business value (“Do we really need to do them all?” ).

CIS Critical Security Control 16: Application Software Security focuses on managing the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise.

The following list summarises the controls that CIS recommends for compliance in Application Software Security.

1. Inventory of Authorised and Unauthorised Applications: Keeping track of all applications installed on systems within the organisation’s network so unauthorised applications can be identified and removed promptly.
2. Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers: Establishing secure configurations for hardware components such as routers and switches as well as software components such as operating systems, web browsers, databases etc., which are used by users during their daily activities related to developing applications or maintaining them after deployment.
3. Secure Configurations for Network Devices Such as Firewalls, Routers, Switches: Configuring network devices such as firewalls, routers and switches securely so they can protect access to internal systems from external threats including malicious actors attempting to gain unauthorised access via exploits targeting vulnerable services running on those devices or through phishing campaigns targeting users accessing them remotely using credentials stored on those devices.
4. Application Software Security: Implementing measures to ensure applications developed by the organisation meet all necessary security requirements before they are deployed into production environment including static code analysis tools scanning source code for vulnerabilities as well as dynamic testing mechanisms testing running applications before they are released into production environment.
5. Controlled Use of Administrative Privileges: Limiting administrative privileges granted to users only when needed so potential risks posed by misuse of those privileges can be minimised while still allowing users access to resources they require during their daily activities related to developing or maintaining applications after deployment into production environment

The full list of controls provides 14 safeguards that should be considered, and include wider practical security controls in Design .

• 16.1 Establish and Maintain a Secure Application Development Process
• 16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities
• 16.3 Perform Root Cause Analysis on Security Vulnerabilities
• 16.4 Establish and Manage an Inventory of Third-Party Software Components
• 16.5 Use Up-to-Date and Trusted Third-Party Software Components
• 16.6 Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities
• 16.7 Use Standard Hardening Configuration Templates for Application Infrastructure
• 16.8 Separate Production and Non-Production Systems
• 16.9 Train Developers in Application Security Concepts and Secure Coding
• 16.10 Apply Secure Design Principles in Application Architectures
• 16.11 Leverage Vetted Modules or Services for Application Security Components
• 16.12 Implement Code-Level Security Checks
• 16.13 Conduct Application Penetration Testing
• 16.14 Conduct Threat Modelling

The CIS Controls remain an industry standard for best practice in cyber security. They form a clear set of baselines and standards that Design Leads, Development Teams and Architecture Governance functions can adopt to ensure maturity and compliance in their Application delivery.

Governance and Assurance Frameworks

While the following frameworks do not directly provide a Set of Control Standards, they do support a range of Best Practice guidelines, Principles, Risk Frameworks and maturity approaches that are relevant to Application Security.

NCSC Application Security Guidance

The National Cyber Security Centre (NCSC) provides guidance and principles on application security to help organisations protect their applications from potential cyber threats.

As part of its Cyber Assurance approach, it provides guidance in areas such as secure development, patching and hardening, authentication and access control, data protection, logging and monitoring, and incident response.

• Secure development to ensure secure coding practices are followed, such as avoiding the use of deprecated or insecure code libraries or functions.
• Patching and hardening to ensure all applications are up-to-date with the latest security patches and that configuration settings are not open to misuse.
• Authentication and access to ensure only authorised users can access the application,
• Data protection controls to ensure sensitive data is stored securely.
• Logging and monitoring to detect any suspicious activity or malicious behaviour within an application.
• Incident response plan to outline what to do when an event does occur. .

The NCSC Application Security Guidance provides a clear set of principles, which can be used as part of any system assessment, assurance or design review.

1. Secure development is everyone’s concern
2. Keep your security knowledge sharp
3. Produce clean & maintainable code
4. Secure your development environment
5. Protect your code repository
6. Secure the build and deployment pipeline
7. Continually test your security
8. Plan for security flaws

While they provide guidance, teams will need to develop the controls needed to successfully follow each principle. For Example “Protect your code repository” could include technical controls around “Data at Rest”, “Data in Transit”, “Data in Use”, Auditing and Logging, Identify and Access Management, as well as administrative controls such as “Security Vetting”, “Joiners Movers Leavers”, “Acceptable Use Policy”, “Security Training” etc.

OSWAP

The Open Web Application Security Project (OWASP) is a nonprofit organisation that works to improve the security of software. It provides freely available, globally recognised guidance and tools that help organisations develop secure software. OWASP focuses on providing guidance and tools that are accessible to everyone, regardless of skill level or industry. Its main goal is to help developers create secure applications by providing comprehensive guidance on identifying and preventing common security vulnerabilities. The organisation also hosts conferences, training sessions, and other events to further its mission of promoting secure software development.

The OWASP Application Security Verification Standard(ASVS) provides a basis for designing, building, and testing technical application security controls. It establishes three verification levels:

• Level 1: low assurance levels, completely penetration testable
• Level 2: applications containing sensitive data, recommended for most apps
• Level 3: applications performing high-value transactions, containing sensitive medical data, or requiring the highest level of trust

These OSWAP policies and guidelines related to application development and maintenance are designed to help organisations develop secure software. This includes:

1. Secure by Design: Security should be built into each phase of the software development life cycle. This includes considering security risks during the requirements, design, implementation, testing and deployment phases.
2. Secure Code Review: Conduct regular code reviews throughout the development process to identify potential security vulnerabilities early on.
3. Vulnerability Management: Identify, prioritise and address known vulnerabilities in code and components regularly.
4. Security Testing: Use automated security testing tools as well as manual penetration testing to detect any weaknesses or vulnerabilities in the code.
5. Application Hardening: Harden applications and systems to reduce their attack surface and limit access to only authorised users and processes.
6. Patching: Keep all third-party components up-to-date with the latest security patches to prevent exploitation of known vulnerabilities.
7. Incident Response: Develop a comprehensive incident response plan that outlines roles, responsibilities and procedures for responding to security incidents quickly and efficiently.

These OSWAP guidelines are consistent with the ISO27000 and NCSC guidelines, providing confidence that Best Practice is consistent across different Frameworks. OSWAP is well regarded, and widely used. Typically the choice of framework will depend on the organisation’s wider Risk management approach, and the Assurance/Governance framework that it operates in.

COBIT Governance Framework

COBIT is an information technology governance and control framework that can be used to help manage IT investments and ensure that they are properly secured. COBIT controls provide a comprehensive set of management guidelines and best practices for ensuring the security of application development and maintenance processes. The implementation of processes, KPIs and administrative controls, along with a governance framework, it can help reduce the risk of data breaches, malicious attacks, and other cyber security threats.

The COBIT “controls” are more similar to the standards and guidelines that we have discussed elsewhere. While they describe process, and management systems, ( again more of the How ), they dont provide measurable end states that we come to expect with security controls ( the “What”). The COBIT “controls” that aligned to application development and maintenance include:

1. Establishing a secure development life-cycle (SDLC) process: This includes setting up policies and procedures for managing the entire software development process from concept to launch. It also includes establishing code review processes, setting up version control systems, and conducting penetration testing.
2. Ensuring secure coding standards: This includes setting up coding standards to prevent common coding mistakes such as buffer overflows, SQL injection attacks, cross-site scripting vulnerabilities, etc.
3. Utilising secure coding tools: This includes using secure coding tools such as static analysis tools to identify potential vulnerabilities before they become exploitable flaws in production code.
4. Testing applications for security vulnerabilities: This includes conducting both manual and automated tests to identify any potential security vulnerabilities in the application code before it is released into production.
5. Establishing secure change management: This includes establishing policies and procedures for securely maintaining existing applications as well as introducing new features or patches without compromising the overall security of the system.

The framework is business (IT Management) focused and defines a set of generic processes for the management of technology delivery. It provides a similar approach to the CMMI mechanism, that gives organisations a scoring against a number of KPIs or process attributes to be able to measure compliance and progress. ISACA provides a mapping of COBIT 5 to ISO 27000/ITIL. In the design of an organisation’s ISMS, COBIT can provide a useful perspective on how IT design, development and operations should be aligned to the security risk perspective.

NIST SP 800–218 and ISO/IEC/IEEE 42010

NIST has also developed NIST SP 800-218 a secure Software Development Framework, that further refines the software development practices. It aims to further mature the controls around application delivery (especially in formal, compliance and regulatory environments).

It  provides guidance on how to securely develop, design, and maintain applications, focusing on the process of development, including requirements gathering, architecture design, code reviews, testing and security validation. It provides recommendations for incorporating security into the application development life cycle.

ISO/IEC/IEEE 42010 provides an Internationally agreed framework for the design and development of secure applications. It focuses on the principles of secure development and best practices in software engineering. The framework emphasises secure coding techniques and secure development processes such as threat modelling, system architecture design, risk assessment and mitigation strategies. It provides guidance on how to design and implement security controls such as authentication mechanisms, access control policies and encryption algorithms. It outlines steps to ensure that applications remain secure throughout their entire life-cycle. ISO40210:2011 is usually considered in safety critical systems and National Critical Infrastructure projects.

CMMI

The CMMI (Capability Maturity Model Integration) process and standards provide a framework to ensure that the development and maintenance of applications is carried out in a secure, efficient and effective manner.

The CMMI [Cyber Maturity Platform]https://www.isaca.org/enterprise/cmmi-cybermaturity-platform) process encourages the application development team to build quality into the product by assessing risk, improving processes, measuring performance and ensuring compliance with industry standards. This helps to reduce security vulnerabilities that may be present in the application and its associated systems. In addition, the CMMI framework(s) promotes greater collaboration between software developers, testers, project managers and other stakeholders involved in the application development life cycle, helping to identify potential security threats quickly and take appropriate action for prevention or remediation. The benefits of the CMMI approach is that it is seen as an approach that can be understood and used by the business, and adopted as part of a wider corporate governance and assurance programme.

"CMMI Security is an integrated set of best practices that improves<br>performance and key capabilities for organizations to assess, enhance, and improve their approach to security beyond compliance."

“Due Care”

Legislation provides an number of obligations to Company directors to exhibit “Due Care” when handling sensitive data. Often dismissed as a ‘Nice to Have’, these technical controls are key to ensuring that applications, services and user data remains secure. We will cover these obligations in more detail in a separate article, but in short:

Companies and their Directors must ensure the business understand(s) the importance of data protection and cyber security, and exercises due care in the development, implementation and maintenance of applications. The Officers must be aware of and comply with all applicable laws and regulations related to data protection and cyber security (e.g. GDPR, HIPAA, Sarbanes-Oxley, etc).

In the UK the ICO provides oversight, enforcement and guidance. The media provides much coverage on the impact of failure to implement the right controls, and the failure to take “Due Care”.

References: GDPR and Data Protection, HIPAA Security Rule, Sarbanes-Oxley Act, NIST Cybersecurity Framework, UK Data Protection Act

Summary

These frameworks and approaches do overlap, which helps to provide confidence through consistency and coverage.

Picking the right framework, set of controls , policy and baselines will depend on your risk profile, security posture and wider risk management approach. By structuring your business requirements into different levels ( eg Strategic, Operation, Tactical, Programme, Project ), your security requirements ( and hence the chosen set of guidance ) will align to makes the most sense ( and at the right level). For Example, at programme design stage, outline (security) principles can help direct design and allocate responsibility. At the project level, individual teams might be allocated to delivery one or more directives, to consider each directive as a Feature that needs to be added into the backlog. Once in the backlog, the delivery squads can then consider related technical controls that support the Feature.

As threats and vulnerabilities change, new and revised sets of recommended controls are released, risk appetite evolves, Management processes mature. Regular reviews against updated guidance should be considered by teams at each milestone, release and review stages, to ensure they are maintaining their protections, security posture and continue to meet the business needs.

From this guide we can understand the differences and perspectives of each framework and guidance. Picking the right approach and sets of controls should be considered as part of your ISMS and the chosen risk management approach. Within this context, Design leadership can support the selection, adaption and then adoption of the right protection to meet the business, project and cyber needs of the organisation.