Secure Software Development
Understanding security policies and how they apply to development practices is key to delivery of secure software. Unfortunately, most development teams do not have a clear understanding of security implementation. This may be due to several factors, but a common theme is that security professionals speak a different ‘language’ from developers (i.e. requirements vs. controls, code vs. vulnerability, feature vs. risk factors). This lack of a common way to communicate security compliance impedes identification and removal of system vulnerabilities. There are many examples of system and data breaches that have occurred as a result of misunderstood or lax security standards.
This is not to say that there are not very useful resources already available. The Open Web Application Security Project (OWASP) group regularly publishes advice on how to identify and prevent common code-level vulnerabilities. The HITRUST Common Security Framework (CSF) provides a unified security framework across virtually all of the current compliance and regulatory standards, such as NIST, ISO, and HIPAA (see Figure 1). The Center for Internet Security (CIS) provides open-source resources for hardening of all major operating systems, as well as tools to help establish and maintain secure deployment environments.
Figure 1. HITRUST CSF v. 9.3.1 Control Categories
So while there is no lack of information available for identification and remediation of security risks, it is difficult to determine exactly what will meet a specific organization’s goal for security policy compliance. Even a well organized standard, such as the HITRUST CSF is well over 500 pages! Expecting all of your development teams to read through and understand every aspect is simply not reasonable. Instead, the development team needs guidance to finding the exact resources needed to meet policy via proper controls.
Development Security Policies
To accomplish this, I propose the organization’s solution architects and security experts combine forces to create a set of ‘development security polices”. As shown in Figure 2 and 3, these restatements of standard security policies enable development teams to quickly identify the guidelines, standards, and practices that will meet the compliance objective. In these examples (taken from the HITRUST CSF, version 9.3) the policies are organized based on the control category and objective. The policy statement goes further to define specific ‘indicators’ for when the policy is applicable, ‘controls’ for ensuring compliance, and ‘implications’ to note likely side-effects of compliance. The policy statement then directs the development team to applicable standards, guidelines, practices and useful references.
Control Category: Access Control
Objective Name: Authorized Access to Information Systems
Control Reference: User Authentication for External Connections
Description: Appropriate authentication methods shall be used to control access by remote users.
Indicators –
- OAUTH2/OpenID is required for access to additional internal or external resources
Single-Sign On is required for multi-system access
Multi-factor authentication is required by regulation or business policy (eg. FISMA, PCI, HIPAA, etc.)
Controls –
- Utilization of industry standards and methods (i.e. OAUTH2, MFA, SAML, etc.)
Auditing of system design to ensure compliance with regulations and company standards
Implications –
- Systems that require enhanced authentication mechanisms will need to be carefully reviewed in the design phase to ensure that proper architectural mechanisms are in place to meet the additional requirements.
Related Standards:
OATH2/OpenID Resource Authentication, SAML single-sign on, Kerberos authentication
References:
NIST SP 800-63 Digital Identity Guidelines
Figure 2. Example development security policy for identity management
This approach significantly reduces development team confusion. It restates the security policy in specific terms that a development team can both understand, implement, and test. Finally, it bridges the gap between development groups and security professionals by translating global statements into actionable requirements. Rather than be subject to external security audits, each development team is empowered to evaluate their own systems. The security team gains valuable insights into how development teams operate, especially in agile practices where “shift-left” applies equally to security needs. Finally, by creation and curation of a focused set of defined polices, there is increased adoption of best-practices leading to safer and more reliable software releases.
Control Category: Information System Acquisition, Development, and Maintenance
Objective Name: Correct Processing in Applications
Description:
To ensure the prevention of errors, loss, unauthorized modification or misuse of information in applications, controls shall be designed into applications, including user developed applications to ensure correct processing. These controls shall include the validation of input data, internal processing and output data.
Indicators –
- OAUTH2/OpenID is required for access to additional internal or external resources
Single-Sign On is required for multi-system access
Multi-factor authentication is required by regulation or business policy (eg. FISMA, PCI, HIPAA, etc.)
Controls –
- Utilization of industry standards and methods (i.e. OAUTH2, MFA, SAML, etc.)
Auditing of system design to ensure compliance with regulations and company standards
Implications –
- Systems that require enhanced authentication mechanisms will need to be carefully reviewed in the design phase to ensure that proper architectural mechanisms are in place to meet the additional requirements.
Related Standards:
OWASP Data Validation Security
References:
NIST SP 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
Figure 3. Example development security policy for data integrity
Conclusion
Security teams understand compliance standards and polices. Development teams understand requirements and create solutions to problems. Restating compliance polices as noted in this post will benefit both teams by creating a common security compliance definition. Having these teams work together is crucial to delivery of secure, stable, and productive software.
