S – for Secure or for Standard?
Written by Gerard Frankowski and Maciej Miłostan.
Implementation of a Web application seems to be an easy task. There are plenty of frameworks available and many tutorials. The question is how to do that securely?
Keep security in mind
While designing a new application Software Development Team (SDT) members usually start from functional requirements and are focusing on the core functionality that fulfils defined tasks or support recognised processes. That is not a bad idea, however it is even a better to extend the scope of requirements towards security aspects. Every SDT should realise that the authentication and authorization functionalities, access controls, event logging, accountability are inherent aspects of the software development lifecycle. Security requirement should be considered from the very beginning of that process.
Identify security requirements following the ASVS standard
Even an experienced and security-oriented developer may have a problem to identify all functional and non-functional security requirements. Fortunately, ASVS (Application Security Verification Standard) provided by OWASP (Open Web Application Security Project) lists most of them handily and comprehensively and provides detailed insights on what should be defined, implemented and tested during the Software Development Lifecycle (SDL) process. According to the OWASP, ASVS has two main goals: • to help organisations develop and maintain secure applications. • to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.
Which security verification level is the best for you?
Three security verification levels are defined in the ASVS. Each level is increasing in depth. Level 1 is for low assurance levels and is almost completely penetration testable (there are literally single exceptions, for instance referring to the contents of application log files). Level 2 is for applications that contain sensitive data, which require protection and is the recommended level for most apps. Level 3 is for the most critical applications – applications that perform high-value transactions, contain sensitive medical data, or any application that requires the highest level of trust.
It is worth emphasizing that Level 2 is the recommended baseline for most apps.
Groups of requirements in the ASVS
The following 14 top-level groups of requirements are addressed in the standard: 1) Architecture, Design and Threat Modeling; 2) Authentication; 3) Session Management; 4) Access Control; 5) Validation, Sanitization and Encoding; 6) Stored Cryptography; 7) Error Handling and Logging; 8) Data Protection; 9) Communications; 10) Malicious Code; 11) Business Logic; 12) File and Resources; 13) API and Web Service; finally 14) Configuration. As it may be seen, requirements are grouped per functionality, so not every group applies to all applications – inapplicability of a particular group obviously does not impact conformance with ASVS.
How does Secure Code Training (SCT) deal with ASVS?
Actually, SCT provided knowledge covered by ASVS since the first training event, organised in PSNC (Poznań, Poland) in 2010. This is apparent as SCT refers to a significant extent to security of Web applications. OWASP ASVS is even older (the 1st version had been published in 2009), but only became more recognisable a few years ago. SCT followed this trend, presenting the ASVS standard in general in its 2019 edition. Following the standard is beneficial for everyone: the knowledge is consistently structured and more complete, and applying the described recommendations provides a recognisable compliance.
This year, ASVS will be one of the main compositional axes of the Secure Code Training. We have decided to detail several of the aforementioned standard areas, namely: authentication, authorization & access control as well as error handling and logging verification. Why these?
- Authentication functionality is both critical and exposed. Before you log in, you have to access the login form which, by definition, is usually available for everyone, including malicious hackers. Authentication issues have been presented during earlier SCTs, but the content will be extended and restructured. Moreover, certain recommendations in the area have recently changed significantly, for instance periodic password modification.
- Authorization is less exposed than authentication functionality (as it requires successful login and thus acquiring certain permissions) but, when accessed, similarly critical. Authorization issues have been mentioned during SCTs but there was no dedicated presentation.
- Error handling and logging verification is does not seem to be so exposed, but is important, both in the context of an attacker (construction of a dedicated attack scenario) and the defender (forensics). This area was only briefly mentioned during earlier SCT and never had a dedicated presentation.
ASVS training provided in SCT21
Additionally, during the first day of the training (SCT21 takes place from 6-9 September 2021), we will provide a reminder presentation what is ASVS, how it is structured and for whom it may be beneficial – as this is designed not only for developers, or even project managers.
And besides ASVS, Secure Coding Training will provide you even more knowledge on development of secure applications – e.g. allow to review the Secure Development Life Cycle paradigm in the context of Continuous Integration / Continuous Development approaches, present several static source code analysis tools but also… to practice real hacking in order to win a prize during the HackMe contest.
More knowledge
For more information check the OWASP ASVS web-page and attend Secure Code Training – SCT21 organised by GÉANT GLAD team and WP9T2 source code security experts.
