This blog is drawn from a presentation I gave recently on CITE2014 called “Security Testing or Security by Design?”. The presentations were powersessions similar to the TedTalks.
We all know security is increasingly important. Did you know over 500,000 active cybercriminals are discovering vulnerabilities in IT-systems (both hard- and software) every second at this moment? Last month, McAfee announced that cybercrime is responsible for an estimated loss of €325 billion worldwide. The loss in the Netherlands is approx. €8.8 billion.
My presentation covered the usefulness of pentesting. Pentesting (or “Penetration Testing” or “Security Testing”) includes investigating vulnerabilities in software after it is written. It’s usually performed at the end of a development process or after an (infrastructure) implementation project. I went on to speak about that single moment when software is tested: right before it’s released for production.
Now, it’s important to realise pentesters will only find known vulnerabilities up until that particular moment and, what’s more, they will only find vulnerabilities known to them. A successful pentest indicates your new program or infrastructure is safe for use, but basically it’s just a snapshot: more vulnerabilities may be found an hour later and other pentesters may discover different vulnerabilities. This is why I plead the case for continuous pentesting, but don’t make the mistake of thinking these pentests can be fully automated.
During an interview with Computerworld I stated that pentests should be taken with a pinch of salt. Please conduct pentests if they are mandatory in your organisation for compliance reasons, but think of them as an exam: you want to be sure of the outcome before you take the test. Pentests should be 100% predictable. You can accomplish this by incorporating security into your development process. This way, vulnerabilities can be detected and solved at a very early stage. Executing this strategy will have a negligible effect on your time-to-market at risk, you will save on rework costs and, when launching your product, you will have safe-to-use software, which will prevent misuse and reputational damage.
The way I see it, three things should be done to implement this merger of security and development:
First of all, more (actually a lot more) “Security DNA” should be ‘injected’ into developers, architects and system engineers: they should be more aware of security during development and implementation. We all understand you don’t leave a wallet stuffed with money on your desk or on the back seat of your car. Sadly, this behaviour is commonplace when developing IT infrastructure. Where 500,000 cybercriminals (remember them ;-)) are eagerly awaiting their chance to take our ‘wallets’. Making IT professionals more aware of security is not an easy task: we live in a world where software was due for production yesterday and security is considered unwanted and time consuming. However, some organisations have embraced this new way of dealing with security and their business cases have proven the excercise is worthwhile: they have a better time-to-market and spend less money because they hardly need any software rework done at the end of the development process.
Second, when designing your software, make sure you describe functional requirements regarding security. This requires a different mindset towards security, but essentially a more logical one. For example, I encounter clients who determine whether their data is critical or not while development is taking place, leading them to choices which may cause rework at the end of the process.
Third, add security specialists to your development team. Make sure of their involvement throughout the entire development process, including the design stage. Invite them for team meetings. Ask them to perform code reviews at an early stage. Make them the ‘security conscience’ of the team. And give them only one assignment: “NO vulnerabilities in this software!”. This will increase the quality of your software and will spread the much needed “Security DNA” throughout your organisation. At first, hiring a (part time) security specialist may negatively affect your business case, but in the end you will save money on rework and repeated pentesting.
When you apply these three points, you will dramatically enhance the predictability of your pentests.
Now. We have a challenge: which qualifications make for a good pentester? Whether you have a large organisation with your own security branch or a small organisation hiring external consultants, make sure your pentester is a hacker. Call it an ‘ethical hacker’ if you want to, but it’s all the same to me. Why a hacker? Well, these people think out of the box and they take a different approach towards software and IT-systems exposing vulnerabilities your developers haven’t even thought of.
So. We have another challenge: which qualifications make for a good hacker? Hackers need to be creative, but also equipped with in depth technical knowledge of IT. Most of all, they need “Passion For Hacking”. IT is all around us (internet, devices, applications) and it’s fast: software updates give birth to new vulnerabilities on a daily basis. Hacker make their way through this world keeping an eye out for orthodox usage of IT-systems; often they just stumble upon vulnerabilities. Therefore, allow hackers enough time when they search your systems. Grant them 20 or 200 hours: it makes all the difference in the world. Time plays an important role regarding the depth of your security test and it will determine the number of issues found.
Furthermore, I’m a strong believer in this: “Be receptive to what the world sends your way, it could probably help you”. I mean this: every company should start a Responsible Disclosure program. Companies who already have a program like this, usually have a link on their website where righteous people can report security issues and vulnerabilities found in their IT-systems. Not a single cybercriminal will leave you a message, but hackers with passion can report their findings in a responsible way, ensured of confidentiality. I’m convinced more ‘good’ people than ‘bad’ people exist and they will help you; just make sure you give them your gratitude rather than a phone call from an angry lawyer.
I witnessed a perfect example of this two years ago at the annual security conference called Hack In The Box. Two young hackers presented how they had hacked into KPN’s set top boxes. After they had finished, the CISO of KPN (Jaya Baloo) stepped forward and came on stage. She handed two t-shirts to the guys. The messages on the shirts read “I hacked KPN and all I got was this lousy shirt”. Everybody laughed and it has made the hacker community turn ‘pro KPN’ (actually, ‘pro Jaya Baloo’) ever since. And this is exactly how companies should react: “Thank you for pointing out the vulnerabilities I have in my systems and thank you for allowing me to fix them, before real damage is done”.
Back to the original point of my blog: “Security Testing or Security by Design?” If you want solid security for your IT-systems, start with “Security by Design” and make sure your “security Testing” becomes 100% predictable.
What shape is your security program in at this moment? What changes will you make tomorrow? And how are you going to use the passion of the hackers?
