Enable software developers to build secure applications by design with OWASP SKF
Zerocopter’s CTO Riccardo ten Cate and his brother Glenn ten Cate have been working on and donated an entire knowledge framework solely dedicated to help developers make their code secure by design to OWASP.
Riccardo specializes in application security and has extensive knowledge in securing applications in multiple coding languages. Riccardo has many years of experience in training and guiding development teams becoming more mature and making their applications secure by design.
Glenn who is a coder, hacker, speaker, trainer and security researcher employed at ING Belgium Glenn has over 15 years experience in the field of security. And one of the founders of defensive development def[dev]eu a security training and conference series dedicated to helping you build and maintain secure software and also speaking at multiple other security conferences in the world. Glenns goal is to create an open-source software development life cycle with the tools and knowledge gathered over the years.
Over the last couple of weeks they have seen a noticeable increase in downloads for the OWASP Security Knowledge Framework, it seems like people are looking for new resources to educate themselves and their teams. In this blog Riccardo and Glenn will tell you more about the OWASP Security Knowledge Framework.
A platform for developers
Have you ever felt overwhelmed with all the new vulnerabilities and best practices going around in the wild for web development?
Working in the field of information security we can assure you that even for us experts whom’s day to day job is to monitor all new developments in the security field it's already hard to keep up with the latest trends.
Looking at the responsibilities software developers already have with respect to, maintainability, performance, architecture, etc, we felt responsible for giving the developers a platform where they can easily get the right information on the spot for whatever purpose or technology stack they were going to work on.
We wanted to enable the software developers to build secure applications by design that was accessible for everybody.
So, the open source OWASP Security Knowledge Framework was born!!
After all the developments we went through over the years we wanted to make a small guide to explain the best practices for the OWASP Security Knowledge Framework (OWASP SKF). In this blog you will find tips and tricks on how to utilize the framework to its full potential.
Before we go into too many details about OWASP SKF we first want to give you an idea what it can do for you!
What is OWASP SKF you ask?
Over 15 years of experience in web application security bundled into a single application. The Security Knowledge Framework is a vital asset to the coding toolkit of you and your development team. Use OWASP SKF to learn and integrate security by design in your web application.
OWASP SKF is an open source security knowledge base including manageable projects with checklists and best practice code examples in multiple programming languages showing you how to prevent hackers gaining access and running exploits on your application.
In a nutshell:
Training developers in writing secure code
Security by design, early feedback of possible security issues
Code examples for secure coding (secure design patterns)
Labs and write-up to train your exploitation/mitigation skills on
1. Checklists for security requirements
From the get go OWASP SKF is provisioned with checklists coming from the following standard, the OWASP ASVS which stands for Application Security Verification Standard. What better way to describe what the ASVS can do for you than to get the description from their own web page itself:
The primary aim of the OWASP Application Security Verification Standard (ASVS) Project is to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. The requirements were developed with the following objectives in mind:
Use as a metric - Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,
Use as guidance - Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and
Use during procurement - Provide a basis for specifying application security verification requirements in contracts.
Now, the problem with ASVS is that it has become quite an extensive checklist. This checklist you probably do not want to iterate over and over again for each functionality you want to enrich your application with right?
SKF can help you with this, and it simply starts by adding a new project!
After adding your first project it is time to ask the SKF for security requirements. To get started with getting the requirements, SKF will guide you through a special wizard that will help you select the right topics that are covered within the ASVS. After following the wizard, you will be presented with a set of security controls that matches with the technology stacks you want to work on, and the type of features that you wanted to enrich your application with.
Not only does the SKF now select from the ASVS the right security requirements for you, it also correlates each and every item of the ASVS to knowledge base items. These knowledge base items give a general description and solution of the security requirements, this provides more context for the developer to get a better understanding of what he is actually trying to mitigate by following the guidelines.
Don’t like working with ASVS and do you have your own internal standard that you want to utilize in the framework? No problem, SKF also lets you introduce your own standards, checklists, and expert system easily through the UI.
Start provisioning your own checklists with an expert system questionnaire and start adding checklist items!
We now added a new checklist for our own internal company. We added a question to the expert system and correlated the security control with the questionnaire. Now, let’s see what happens when we ask our own internal policy for requirements!
As we have seen with generating the security requirements, the SKF can correlate security controls with knowledge base items. These knowledge base items you can easily edit and add yourself through the UI. The same principle applies for adding or updating your code examples and best practices.
2. OWASP SKF chatbot feature
Chatbots are software agents that interact with the user in a conversation. A chatbot is a service which is provided by websites so that users are easily able to fetch information interactively. They can reach out to large audience on messaging apps and be more effective. A chatbot provides a speedy and quick response and is available around the clock. Such programs are often designed to convincingly simulate how a human would behave as a conversational partner. Chatbot will be an attempt to reduce the pain of the user and will help users in finding solutions to their problems and thus improving the security of code and infrastructure. This will be integrated into various chat systems to make it easier to use.
SKF-Chatbot is the bot which provides information about the vulnerabilities as included in the SKF knowledge base to the users. The current version helps the user to get the information about a topic's description, solution and code examples to the user in various languages like python, ruby, flask, java etc.
The SKF bot needs an additional Hubot client to be integrated in your Slack/Gitter workspaces. How to set up the Hubot client can be found here
3. Train your developers in becoming security champions!
After you have implemented a new feature and followed all the right guidelines as described by the security requirements we still need to learn how to verify if our implementation was performed correctly. SKF comes with 50+ (and growing by the day) of security labs that can be deployed through the UI by the click of a button!
Not only gives this your or your developers a sandboxed environment to improve verification skills on, each and every lab has an extensive step-by-step write up on how to find and exploit the vulnerabilities!
How this feature works under the hood is as follows:
How to set it up locally?
In order to get SKF running on your local machine we start by cloning the github repository:
After cloning the github repository we cd into the root folder of the skf-flask project where we first want to investigate the docker compose file and it’s configuration options!If you want SKF to automatically deploy the labs in your kubernetes cluster you need to provide the path where your client certificate/config file is stored in the path of the docker-compose file.
Now, the docker compose file has more options for you to configure if you want to make it suitable for a production environment. One of these changes includes i.e. the configuration of the DB connection string to have a persistent database on a location of your choosing.
Getting your OWASP SKF instance ready to deploy the labs on your local machine we need to configure your local docker desktop to also enable a local kubernetes cluster. In order to achieve this we go to “Docker desktop -> preferences” where we will find the tab “Kubernetes”
Following to this tab we find the following screen:
First we want to select “Enable Kubernetes” after which we press on “Apply and restart” to make your Docker desktop pull all the configuration files needed for a successful Kubernetes installation.
For Linux users you may want to look at Minikube for deploying locally. Alternatively if you do not want to go through all the hassle of installing a local kubernetes cluster you can also provide the configuration file from the cloud provider of your choosing, or simply choose to clone the lab repository and run them as flask applications with python as described here. After setting up our local cluster it is time to perform a “docker-compose up” command in the root directory of the SKF project.
**Note: when running SKF in production or on a cloud environment it is recommended to set a cron job that removes all the images nightly. This helps you not paying for images that are no longer used by your users that are forgotten to be destroyed after use**
Docker compose does a couple of things for us. First, it pulls all the images needed to run SKF successfully. The containers that it pulls are the following:
SKF - API
The backend of the security knowledge framework, the backend is based on Python-Flask.
SKF - Angular
The front-end of the security knowledge framework, the front-end is based on Angular TypeScript
We have created a Nginx reverse proxy that will receive a public IP (when deploying in cloud). This will pass through the api request to the skf backend api when hitting /api. and for / it redirects it to the skf angular application.
Messaging with RabbitMQ enables software applications to connect and scale. Applications can connect to each other, as components of a larger application, or to user devices and data. In the context of SKF it is used to connect the SKF API with the kubernetes client to create a deployment queue. (special shoutout to Olivier Beg for giving us the inspiration to go with RabbitMQ!)
After a successful Docker compose you will have the following infrastructure set up for you on your host machine:
And that is all there is to it, use SKF for making your applications secure, by design!
Please note that the automatic deployments for the SKF labs is still in beta mode at the moment and that it can be found on the OWASP SKF Dev branch. The Stable version of OWASP SKF is found here. Whereas the Beta deployment needs the Docker compose because of all the other components that need to be running, the SKF stable version can still be run with a simple one-liner that is found