Skip to main content

Commerce

Understanding Security Policies for Development

Security Policy and Development

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.

Hitrust Csf Control Category

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Benjamin Lieberman, Director

Ben Lieberman is currently a Director in the Perficient Inc., Custom Development and DevSecOps (CDDO) delivery group. Dr. Lieberman has over twenty five years of software and systems development experience across a wide range of industries, including financial, government, telecommunications, life sciences, travel services, and space launch systems. He is highly experienced on multiple software development topics, including requirements analysis, system analysis and design, secure systems development, configuration management, and automated build/deployment (aka DevSecOps). He also has direct development experience in multiple languages including Python, Java, C#, C++, and Salesforce (APEX) coding languages, and works directly with development teams on agile delivery practices. Dr. Lieberman is an accomplished professional writer with a book (“The Art of Software Modeling”, Auerbach Publishing) and over three dozen professional IT articles to his credit. Dr. Lieberman holds a doctorate degree in Biophysics and Genetics from the University of Colorado, Anschutz Medical Center, Denver, Colorado.

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram