Thursday, December 3, 2015

Secure Coding Skills Development Features

Out of the feedback and gameplay data of our Secure Code Warrior platform, we learned that most developers found the challenges really challenging and they felt they needed some support or helpline to advance their skills development. Many realised they might not be so good in secure coding as they expected.

To address this feedback, our team have implemented some exciting features to ensure that users without any security knowledge are able to learn
  • The “Training Ground”, these are entry level missions that focus on one set of vulnerabilities only. Aspirant Secure Code Warriors can start off here and practice on a range of data validation issues like code injection.
Several of our Clients have provided us feedback on the requirement to enable developers to train in topics which are of focus in classroom training they deliver. This allows
developers to apply the teachings of the topics taught in class by completing topic specific missions consisting of real world, language specific challenges. As a result the “Training Ground” is now available where users complete missions that focus on single topics or vulnerability categories (e.g. authentication and access control, data handling). These category-based missions exposes the user to basic training on the main categories of application security vulnerabilities and sets them up for the full game where they will be confronted with a combination of different vulnerabilities to identify and remediate.

  • A “Hinting” system– Recognising that users may not yet have the skills to answer questions they are confronted with and that we need to equip them with this, we have implemented a hinting system. Users can learn by the direction provided by hints that they request:
    1. First hint will give a general understanding of the problem
    2. Further hints will give specific assistance by pointing the developer to a specific code block, or removing some wrong answers.
    3. Last hint will almost give the answer completely away. 
Obviously, the more hints that a user requests, the less points will be awarded for the question should they answer it correctly

  • Response Feedback – Our users have requested that they would like to know more about why they got a question right. We acknowledge that this is again something that can encourage further learning and as a result we have implemented a feedback system. Users are given an explanation of why the question they have answered is correct.


Bonus - LinkedIn Integration

Players can now demonstrate their level of skill in secure coding by publishing their security maturity level and player statistics on LinkedIn. A unique link will be generated that allows anyone on LinkedIn to view your individual player statistics. 




Friday, October 30, 2015

Improving Application Security with University Students

Having seen the cost associated with fixing vulnerable code first hand, the Secure Code Warrior team is passionate about equipping developers with the skills necessary to prevent such flaws from being introduced in the first place.
Our intention was to build a gamified platform that could be used by seasoned software developers and newcomers alike. To achieve this, we worked with the University of Sydney to provide students of the INFO5010 class (an applied information security subject) with access to our platform for a month.
Together with the lecturer of the INFO5010 subject, Luke Anderson, the students completed SCW challenges in the JAVA language with a specific focus on Java Server Pages (JSP) and the JAVA Spring Framework. The objective here was to expose the students to secure coding practices and provide them with a comparative assessment of their own skill set.
The Secure Code Warrior platform ranks developers in four (4) maturity categories based on the number of challenges played and overall accuracy. We expected most students to end up in the “beginner” or “security aware” categories.
SCW maturity
Of the twenty-five (25) students who participated, three (3) students topped the leader board by solving even the most difficult JAVA Spring challenges. These students achieved the “Security Skilled” developer rank.
USYD2
Two (2) of them achieved the “Security Aware” scale but overall it was clear that the level of security knowledge of the students was diverse.
Most students gained points in the “data handling” vulnerabilities, which primarily includes things like SQL and Code Injections, Cross-Site Scripting, etc. The majority of the mistakes were made in the “authentication and access control” challenges.
Feedback from the students indicated that they generally found the challenges to be quite difficult. As a result, we have implemented some learning attributes to the platform which are able to provide further training for those that are still in the early stages of their skill development. It was great to see the students battling it out for the top of the leader board and it became clear the gamification of the platform engaged with the competitive nature of the students.
At the end of the month, the results were used to benchmark the students against their peers and from this they were awarded marks. This formed part their overall assessment for the course.
“Secure Code Warrior specifically assesses a respondent’s ability to identify security weaknesses in existing code and fix them. Writing assessments targeting this particular skill is quite difficult, which can lead to a dull experience for students. SCW provided my students with a series of challenging, fun and realistic scenarios that allowed me to effectively differentiate students in regard to this particular skill.” – Luke Anderson, University of Sydney
A big congratulations and thanks to all students of INFO5010 for their effort, courage and feedback while participating on our platform. We learned a lot from watching you play!

Thursday, August 27, 2015

Security Awareness of Software Developers

As Chief Architect and Co-Founder of the Secure Code Warrior platform, I am trying to stay close to the developer community and especially the ones that are interested in cyber security and secure development. One of those touch points was last week in Berlin (Germany), during a cyber security training conference of the SANS Institute where I was teaching the SEC542: Web Application Hacking course. There were at least 10 developers out of the 20 attendees (which is very positive because I have never had so many developer in one class).
On the first day, I surveyed the class and checked how many knew what a “SQL injection” and “Cross-Site Scripting (XSS)” attack was.  Both weaknesses that have been around since 1999 (first publication of SQL in Phrack magazine and XSS 10th birthday was in 2009 according to Microsoft) . Most of the ten developers had heard of these terms, or had been confronted with them during an audit or just because they were interested in the subject.
On day 5, the second last day of the training, we focused on the technical consequences of such vulnerabilities. I demonstrated to them how hackers abuse the SQL weaknesses to gain access to data stored in a SQL database but also how this could be further abused to gain access to the operating system under certain conditions. I also used the Browser Exploitation Framework to show the impact of a simple javascript injection and how this could lead to controlling the victim’s browser and manipulating session data.
Most of the developers in the class never knew this was possible with those types of attacks. They knew these security concerns were important but had never thought the consequences could be so devastating for an organisation. This shows me that even developers who are interested in the subject (why else would they be in the class room in the first place?) do not necessarily have sufficient awareness around security weaknesses and do not think the same way as malicious hackers.
How are developers supposed to write secure code if nobody ever teaches them about the consequences and more importantly how to prevent writing these vulnerabilities in their respective programming frameworks in the first place?
Pieter

Thursday, July 2, 2015

State of Application Security 2015

In May 2015 the SANS Institute released survey results from 435 participants around application security practices from the perspectives of defenders (security engineers and internal security team), breakers (penetration testers) and builders (software developers).
While a closer alignment bodes well for the future of applications, results also show continued gaps between the groups, such as builders putting security off on ‘someone else’ and defenders trying to force security through compliance reviews and penetration testing rather than working with builders to design and build in security from the start.
Having been on the breaker/defender side for a long time in my career, I certainly recognise this behaviour. Penetration testing is often being used to validate the security of software (either during the development cycle or most often at the end or even after going live) and the results coming out of these assessment are always written from the breaker’s perspective. They often do not succeeded into describing their findings and recommendations in a language that is directly usable for these builders, or the breakers just do not understand enough from the application architecture and coding in order to give valuable recommendations.
Also, the builders often do not have a good understanding of what all these security vulnerabilities mean and “security” is something they think the infrastructure team, security engineers or even development frameworks should solve. The builder’s main drivers (often set by company management) are to build end-user features and meeting time-to-market expectations, not making sure their code is written in a safe and secure manner … even if their software is controlling traffic light systems, running air-traffic systems, allowing people to do online banking or simply storing health information about a country’s citizens.
Since starting Secure Code Warrior with an extremely smart team of ex-breakers & ex-defenders (who now all transformed into builders themselves), I have become a big fan of letting your builders verify their own code for security problems and making sure they have the knowledge and automated tools (think agile & continuous integration) to make sure any code they push to the code repositories has been checked for the most critical web application vulnerabilities.
I think that is exactly why Microsoft Azure App Service, a cloud service for building websites and mobile apps, has announced a new feature in June 2015 to automatically scan web applications for security issues. Google already has something similar named Google Cloud Security Scanner in beta running since February 2015.
Pieter