This event is about functional security testing and is very interesting for many reasons.
You can use the following information to convince yourself or your management.
It's not (only) because we were blocked at Home during the COVID time.
We also realized that, in software security, we can have some "red team" (or offensive security testers aka Pentesters) that are specializing in testing the security of a software by acting like a hacker. They are very much specialized, using complex software but, most of the time, they are focusing on the "technological hack".
They exploit a known vulnerability in an outdated application server, are looking for a forgotten admin page, try to perform some brute force, ... They are following a hacker's playbook, behaving like a complete outsider with a lot of hacking skills.
But, in the real world, the risks are also coming from functionalities that are not well designed or badly implemented. To find those, real vulnerabilities, you don't necessarily need a security expert but more a product expert, someone that knows the product and how it is built. In another words, you need a Software Developer, a Quality Assurance, a Product Owner, or anyone that is building the software. They have product expertise because they are building it!
Now this group of people is not necessarily aware about the hacker's mindset, the way he thinks and can abuse your product. What if we give this expert group some training, support, and dedicated time to become a hacker?
Well if you're here reading this page it means that the idea was very successful for us and we want to share our recipe to the world hoping that it'll help other like it helped us.
This reason is simple. Like the bugs, whatever your commitment to security or the skills of your engineers, you will have vulnerabilities. Discovering, by yourself your vulnerabilities will give you some time to fix them, understand them (for the next feature), without the pressure of a serious security incident. Your business continues because your customers are trusting your products and your company. In addition to operational or legal costs, a security incident could greatly impact your image.
Discovering a security vulnerability is like discovering a bug without your customer being impacted: it is comfortable because you have time to address it.
In all our hacking events, we always found some crunchy problems. Some were simple to fix, some were more complex and some were already known but accepted as impossible to exploit...until a smart product owner finds a creative way to exploit it.
For the companies following stric security policies during the developement lifecycle (like Microsoft Security Development Lifecycle) it may be strange to have such event organized. The classic touchpoints are usually
- Pentesting
- Threat modelling (at design or after implementation)
They are good touchpoints (and needs to be continued) but they are usually regular but time-constrained and performed (or animated) by experts outside of the products.
Having product expert running something similar (via the hacking event) is producing much more innovative scenario and some forgotten uses cases are sometimes rediscovered by the one that designed them !
Bringing security expertise and product expertise together is THE best vulnerability catcher!
We experienced that the DecSecOps teams had a great set of skills regarding the technical and functional part, quality, usability, operations but not so much security.
Why is that ? Because security is seen as a different job, with different skills and also often against the business or the software craftsmanship.
It is true that Information Security is a job family by itself, but if you have 10 security experts in 1 team, surrounded by 1000 developers, there are a lot of chances that some design and features will not be carefully reviewed. The best approach is to have synergy between security and software engineering and it starts with making them work together, understand each other.
The DevSecOps teams will, by attending to a hacking event, gain theoretical and practical knowledge:
- Direct training on security testing: organizing a presentation of security testing methodology and tools will allow the teams to reuse the methods learned during the event
- Practicing security testing on their own product: a good training always goes with a hands-on session. In hacking event the team will directly uses their new knowledge, applying it on their own product.
This last added value is quite important. In addition to finding vulnerabilities, learning, and practicing on security testing, it's a fun event for the attendees.
One of the outcomes of the event survey is that, despite the complexity of starting a new task with a new mindset, the event was really fun and the team had a good time. We have also seen teams very much involved in the contest and working with very structured approaches.
Overall, the event is about spending 1.5 days outside of their normal work, but still working to improve their product in an efficient way. It is also about doing, in teams, something interesting and oddly satisfying.
Finally, this event is a fun contest, with rewards and fame for the best teams.