Writing secure software: OWASP guidelines for code quality

In this article we will analyze a series of guidelines promoted by Agenzia per l'Italia Digitale (AgID) for the development of secure software in the public administration.

The guidelines are the result of a series of documents and contributions that AgID has put together starting from 2017, with the publication of the Safety Guidelines for Application Development, and were then detailed in four technical annexes created over the following years (2018-2020 ):

• Annex 1- Guidelines for the adoption of a secure software development cycle
• Annex 2 - Guidelines for secure code development
• Annex 3 - Configuration guidelines to adapt the security of the basic software
• Annex 4 - Guidelines for the modeling of threats and identification of mitigation actions in compliance with the principles of Secure / Privacy by Design

The objective of these documents is to provide the Public Administration with a real architectural model that allows the safe development of both critical and non-critical services, defining the principles and guidelines to guarantee those "technical measures and organizational structures appropriate to the risk "provided for by articles 5 and 32 of the GDPR and further confirmed in the NIS Directive 2016/1148 (Network and Information Security).

In the following paragraphs we will try to provide a useful summary of the 4 annexes; however, it's strongly advisable to read them in their entirety as they contain a summary of the best practices contained in the main international security frameworks: Open Web Application Security Project (OWASP ), Software Assurance Forum for Excellence in Code (SAFECODE), SANS Software Security Institute (SANS SSI), Web Application Security Consortium (WASC), and many more. However, it's important to keep in mind that most of the suggested countermeasures will require some programming experience and are meant for software developers with a solid coding school background.

The guidelines collected in these documents, although designed for the public service, can be used by any private company interested in securing their technical, organizational and management processes in the field of software development, as well for the whole IT security lifecycle of services and software applications. Moreover, it has assumed fundamental importance in recent years since, in addition to playing a primary role in guaranteeing the availability, integrity and confidentiality of information, it is directly linked to the privacy principles provided for by the legal system.

1. Secure software development lifecycle

The first annex aims to provide guidelines for undertaking a "secure" software development process, during all phases of the Software Development Life Cycle (SDLC) through the identification and implementation of appropriate safety.

The document is divided into the following key points:

• Areas of Application. This section explains how the need for secure software development arises and where it should focus.
• Analysis of initiatives and standards. This section analyzes the national and global scenario providing an overview of the initiatives and the results produced in terms of: methods and models, standard best practices, tools. As a result of this analysis, a Catalog of Security Tools is drawn up.
• Secure Software Development Life Cycle (SSDLC). This section deals with the analysis of methodologies and processes, as well as the various existing SDLC methods and models, with the aim of identifying the characteristics that make a software development cycle safe and effective.
• Security in all phases of the software development cycle: an in-depth study of the various SDLC phases in order to emphasize the need to consider security aspects from the very beginning of the SDLC itself.
• Training: section that focuses attention on the fact that many of the current security problems derive from design and / or implementation errors; these problems can only be solved by having trained and knowledgeable staff.
  Professional certifications. A list of the main InfoSec certifications available worldwide.

This annex strongly relies upon the standards defined by the OWASP community, with particular regard to the list of the most critical web application vulnerabilities (OWASP Top 10 Web Application Security Risks). Specifically, the document compares the vulnerabilities highlighted in the latest OWASP report (November 2017) with those identified in the previous report (OWASP Top 10 - 2013), as can be seen from the following table:

2. Secure Software Development

The second annex aims to support, through appropriate guidelines, the development of secure software applications. The guidelines presented constitute a set of best practices to be followed in order to prevent any security problems in the code, and at the same time provide a useful tool in identifying possible vulnerabilities in the source code and the related countermeasures to be applied.

The document is structured as follows:

• Chapter 1. Generalities and purpose of the document;
• Chapter 2. Applicable and Reference Documentation;
• Chapter 3. Definitions and acronyms;
• Chapter 4. Introduction to secure applications;
• Chapter 5. Set of general and transversal recommendations for implementation choices;
• Chapter 6. List of the main software vulnerabilities, accompanied by specific examples and related countermeasures to be adopted;
• Chapter 7. Best practices for the development languages ​​used (C / C ++, Java, PL / SQL, Javascript, PyThon, C #, ASP, ASP.NET, PHP, VBNET, AJAX, GO) and a set of measures to be taken in order to reduce exposure to application security issues.

This is an extremely detailed document that provides an exhaustive overview of the design guidelines and standards most used for the development of modern applications, with particular regard to web applications or applications that require interoperability with the web.

The recommended approach depends on the type of project: in the case of designing applications from scratch, a Secure by Design approach is suggested, while in the case of re-engineering of existing applications, the adoption of a Security Control approach is recommended.

• Secure by Design. During the application security analysis phases of a system architecture (to be defined or under review) it is necessary to implement safe design practices through the identification of security requirements and countermeasures according to the Security by Design Principles. Secure design practices achieve information security through a "Defense in Depth" approach of the application layer. "Defense in Depth" aims to minimize damage in the event of a successful attack. In practice, assuming that an attacker manages to overcome the first level of defense (for example by circumventing the authentication check), further more restrictive measures must intervene to hinder its advance (for example, by restricting access privileges to resources to a minimum or by applying the compartmentalization of the application in order to hinder block the propagation of the attack to the entire system).
• Security Control. In case you are making changes on an existing application, you need to keep the following points in mind:
  • identify, quantify and resolve the security risks associated with an existing interface, application and / or system;
  • validate from the point of view of application security the developments made by third parties (supply chain security);
  • protect their information assets and data.

The document also reviews all the main vulnerabilities deriving from the most common programming errors: input validation, file inclusion, insecure deserialization, cross-site scripting, directory traversal, SQL injection, session stealing / hijacking, and so on, indicating time in turn, the best practices to be followed to avoid similar risks: once again the main source of reference is given by OWASP and by the countermeasures identified by the community in response to each of the vulnerabilities indicated.

3. Basic software security configuration

The third annex is dedicated to the identification and definition of some best practices for the secure configuration of the basic software, that is the operating system and the main applications of the computers in use: in other words, this is the activity conventionally known as " hardening ", which concerns not only the configuration of the OS but also the perimeter protections (physical and logical), the network architectures (DMZ, segmentations, etc.), the organizational procedures (which mainly concern the people who work behind the technologies ), the training programs of "security
awareness ", and so on.

The document is applicable to all the main types of basic software, middleware and applications in use by public administrations, and in particular:

• UNIX Operating Systems
• Microsoft Windows Server operating systems
• Windows Client operating systems
• Web Browser
• Workstations
• Web Application Server
• DBMS / Data base server
• Mail Server,
• Enterprise Service Bus
• Main Office Automation applications (Microsoft Office and OpenOffice).

The paragraphs that make up the document go into detail on the individual components (basic software, middleware, office automation, etc.); for each component, an in-depth analysis is carried out from the point of view of security best practices, providing a list of security measures to be adopted in the face of the most common threats in order to reduce exposure to risks for the security of information and services disbursed. In detail, the document is divided as follows:

• List of information security threats, i.e. the main types of attacks compared to basic software, middleware and the most common application software.
• General recommendations: a series of "transversal" indications that create the common basis for addressing the safety problems of specific components.
• List of references for industry-standard hardening operating instructions made available by established and internationally established communities and/or institutions.
• List of configuration baselines, as well as a list of hardening software tools made available by third-party vendors.

The document has a strong technical approach and gives extremely detailed instruction, declined according to the reference operating system and the type of threat that it aims to mitigate. Particular emphasis is given to the need to enable the logging and auditing tools provided by the operating system, so as to accustom system administrators to adopt monitoring procedures and favor the creation of log analysis procedures, which are extremely important in terms of preventing certain threats. particularly relevant in terms of data breach (unauthorized access, incorrect configuration of authorizations, etc.).

4. Threat Modeling and Mitigation Actions

The last annex aims to analyze the context (processes, methods and models) of the design of secure applications, with the aim of providing a set of guidelines for the modeling of threats and consequent identification of mitigation actions, in accordance with the Secure by Design and Privacy by Design principles. This approach constitutes an important phase in the process of preventive identification of security and privacy requirements. It is therefore a document that goes beyond the aspects strictly related to software design (annex 1), code development (annex 2) and application configuration (annex 3), to focus on the aspects of governance, project and process management that constitute the general context of these activities.

The document is structured as follows:

• Needs and areas of application. Introductory chapter that illustrates the importance of implementing adequate countermeasures to anticipate major threats, i.e. acting before they occur, in terms of risks and costs.
• Secure and Privacy by design software. This chapter analyzes the tools and models to support the design phase of secure software, both in existence and in progress: BSA Framework for secure software (BSA), Open Software Assurance Maturity Model (SAMM), Building Security in Maturity Model (BSIMM ), Comprehensive, Light-weight Application Security Process (CLASP), Microsoft's Security Development Lifecycle (SDL), and so on.
• Guidelines for the identification and review of application security and privacy requirements. Chapter dedicated to the definition of some guidelines for the preventive identification of possible threats, the related mitigation actions and for the assessment and prioritization of the threats themselves: particular emphasis is given to the aspects related to the initial modeling, which cannot be separated from the identification the security objectives (confidentiality, integrity, availability), from the creation of a high-level design of the application, from the identification of roles and use scenarios, from an in-depth analysis of the technologies used, of the data flows and relative entry points and exit points of the same.
• Application Example. The last chapter presents an application use case ("Easy Web Site") in which the methodologies, security tools and countermeasures indicated in the previous chapters are used.

References

• Safety Guidelines for Application Development (Agenzia per l'Italia Digitale, 06/05/2020)
• OWASP Top Ten Web Application Security Risks (OWASP, 2017)

Print Friendly & PDF Download