I work as an ethical hacker at MOJ Digital. It’s my job to break into our systems and applications to find any weaknesses that could be exploited by hackers of the less ethical variety. It is important to ensure that citizens feel safe when they are interacting with our services, and to guarantee the privacy of their data.
I work with the same tools and techniques that real-world attackers use to find and fix vulnerabilities in our systems before they are released. I work as an integral part in our development cycle which is how we ensure our security is robust and not someone else’s problem.
Why we have an ethical hacker
The main reason for having an ethical hacker inside the organisation was to move away from treating security as an afterthought. Many organisations only carry out penetration testing at the end of a project and then only re-test if a problem arises. By contrast, we continuously conduct penetration testing using agile processes, in the same way that our developers continuously deliver into production.
I regularly speak to each service’s technical architect so I have a good idea about how the system is structured, the features of the web application and so on. This helps me to identify attack vectors (weak points which can be used to hack into the system) and keep an up-to-date picture of the potential risks and threats. I also work with the team to define the scope for my work and agree on deadlines for writing a vulnerability report so we can decide how and when any vulnerabilities can be addressed.
What’s it like to be an ethical hacker?
The most important thing is that you must really, really like breaking stuff.
I use a suite of tools that most CHECK compliant penetration testing companies use, such as Burp, Nessus, static code analysis tools, and the various tools that are built into Kali Linux. As most of our products have a similar architecture, these tools help me tackle the most common issues efficiently.
However, what makes the testing phase so fun is that often the weaknesses discovered are far removed from ‘the usual suspects’ - subtle interactions and edge cases that are not obvious at first sight. So rather than just looking for the most common issues, such as those listed in the OWASP Top 10, I have to conduct a more thorough analysis.
Having free reign to test products also gives me means I have the opportunity to develop my skills in areas like information security, such as cryptography and cloud security.
A work in progress
In the 6 months since I started we’ve made good progress but there are still some questions which we haven’t fully answered, such as:
- How can we integrate managing and remedying vulnerabilities into our processes?
- How can we resolve critical and high risk vulnerabilities on the fly, or as soon as possible?
- How can we keep track of vulnerabilities after each penetration test?
- How can we keep accreditors up to date with our progress?
- How can product teams communicate efficiently when they have fixed a bug?
We’re always keen to improve how we’re working so if you’ve faced similar issues, have thoughts on how we can get better, or just want to give us a shout, just reply directly to this post or speak to us on Twitter @MOJDigital
4 comments
Comment by Rob posted on
Do you have any open source examples of building security testing into the automated build pipeline?
Comment by anonymous posted on
Several products use static code analysis tools like brakeman and code climate with their CI.
IMO, integrating fuzzing and manual testing in an "automated" manner into our build pipeline is an ongoing challenge, for reasons highlighted in the article.
Comment by chris price posted on
Could I speak to you - perhaps anonymously if needs be - for an article I'm writing on how to become an ethical hacker for a newspaper.
Comment by kram posted on
Of course! If you could email contact-us@digital.justice.gov.uk we'll be in touch.