• Tweet
• Share
• emailshare

• Tweet
• Share
• EmailShare

Hi all,

Six months ago today I started work at Realex Payments as an application security analyst. I was hired straight out of college, and as a student I didn’t have much opportunity to experience real-world security but I did have a long-standing interest and a bit of experience playing about on wargame sites like HackThisSite.org.

During the last six months I’ve been to my first security conference, learned about a myriad of tools that you don’t get to experience on wargame sites (such as Burp Suite, metasploit, and ZAP to name a few) and played in my first Capture the Flag game held by Realex Payments not too long ago. I’ve also learned one of the most important things in application security, which can be trickier than it seems; turning an error message from fuzzing into the chunk of code – the file and line number – where a vulnerability lies.

To be able to figure this out you really need to understand the language you’re working with. It helps if you’ve programmed in it before, it’s not necessary but it certainly saves time! Try exposing yourself to a few different languages that you expect to work with as early as you can. If you haven’t programmed in the language you’re auditing before you’ll need to take some time to become familiar with the syntax, any caveats the language might have (like the unusual variable scope in JavaScript) and be ready to dive into Google early and often. You’ll also need to know the framework, if any, that has been used to develop the application; knowing where to look to find the map between a URL and controller within a MVC webapp is important.

Similarly the tools I mentioned earlier are very useful in validating potential vulnerabilities you find during code reviews, an important step in justifying the bug report (and your jobs existence). You won’t need to prove that every bug exists, but if you can show evidence for most of them developers will tend to trust your judgement for the ones that are more difficult to exploit.

A great way to gain experience with these tools is by playing in Capture the Flag games. There’s many different types of Capture the Flag games, from wargame sites like HackThisSite which are great for learning how to think outside the box and approach security challenges, but can lack realism, to conference games held over the world and online, which tend to be a bit more realistic with actual vulnerable applications loaded onto servers that you then need to break into. A list of these can be found at http://ctftime.org/. Start building up a profile on these, the experience is invaluable and gives you something to talk about in an interview, plus they’re always good fun to participate in with a few friends.

Some other tools that would be useful to know about before looking for a job in application security are Static Analysis tools. These tools can scan over large codebases very quickly and can report on some of the low-hanging fruit like XSS or SQL injection bugs. It won’t help you in checking for some large classes of bugs like logic errors (such as insufficient authorization or authentication bypass bugs), so don’t rely too heavily on these tools. FindBugs and CodePro Analytix are good tools that have Eclipse plugins, but only a small amount of security rules contained within them. RIPS is a useful tool for scanning PHP applications, it is a PHP application itself but runs pretty easily with a WAMP or LAMP stack.

Of course, there’s more to a security job than knowing how to find vulnerabilities and use tools. Bug reports need to be written up clearly and concisely, and people with different backgrounds and experience in IT and security will need the potential threats communicated to them with the right amount of detail – the CEO of your company might want to know why SQL injection is bad, but they probably don’t have the time to get into as much detail as the person who’s got to fix the bug! Take some time to talk to people with different levels of, or no, IT background about recent headlining hacks, like the Sony or Stratfor attacks. Family are great for this, you can bore them with a constant stream of news for weeks on end and they still have to invite you over for dinner.

It can also help to know about any security standards such as PCI DSS that can affect the companies you apply to. Even if these standards are not directly applicable they’re good to have a background knowledge in. In a similar vein would be any threat modelling and risk assessment procedures. There is a bunch of different ways to do these and every company could have their own flavour. Knowing the basic idea of these could put you ahead of the curve when you’re applying for a job.

Finally, the old adage “Information is power” is very true for security. Make sure to keep abreast of security news, and don’t rely on the main papers like The Register for details or you can end up learning about things a few days later than the rest of the internet. Try find the original source of information when you read a news article, and make sure to keep an eye on bugtraq or full-disclosure for interesting bugs like the Skype account hijacking vulnerability, or all of kingcope’s recent 0days. You never know what applications might crop up where, and when a company you work for might use them.

You can’t possibly learn everything, and there’s a lot I didn’t cover that I’ve been over in my time here. There’s so much more to your career than just your job of course – especially when you work in such a friendly and social company as Realex. After you get the basics down just dive into the areas that interest you – it’s the easiest way to keep learning. It’s going to be impossible to specialize in everything, but keep looking into what you like. There’s a lot of opportunity in information security, and you can easily carve out a niche for yourself in the areas you like the most.

Diarmaid McManus, Application Security Analyst