For those who are new to the blog, or just me in general, my name is Maxwell Dulin. I am a Security Engineer/Consultant at a security consulting company called Security Innovation. It feels surreal to go from a wanna-be hacker to doing this professionally! Although I still do not feel up-to-snuff, I'm getting more knowledgeable day-by-day and becoming more comfortable. After finishing my third month as a security consultant, I would like to share some of the insights about being a security consultant. The beginning starts off with skills that should be developed. Then, the article finishes with the biggest benefit/quirk of being a consultant. Enjoy!

Technical Skills

Although I am speaking from the perspective of my company's market, the bulk of engagements are going to be web. Every company has a website which has publicly facing information on it. So, most companies will get their web application tested. Because it is the most common, by far the most important skill to have is understanding web application testing. This includes understanding client side (XSS, CSRF) and server side (mostly API) testing.

After web, the next most common thing to test are mobile applications. Mobile has an entirely different threat model, compared to web. Is the phone rooted or jailbroken? What kind of sensitive data is stored within the application binary or local files? Can authentication be bypassed by forcing screens?... A different threat model but still valuable to know!

From there, it becomes a toss up. Native or thick client's (think Windows or macOS specific client's) are somewhat common to come by. Additionally, with the recent rise of blockchain there has been a major need for people to review these applications (especially considering that it is immutable). IoT and hardware come across here and there. To be honest, these tend to be the most fun projects; I wish these were more common. The frequency of each will depend on the company that you are at and the skills of the people at the company. This is just a rough estimate to being at Security Innovation is like.

Although this is all Security Innovation tends to do, there is also the full on red teaming that happens; this deals a lot with social engineering and physical penetration testing. This is another potential pass to go down!

What Do I Learn Then?

The bread & butter for most engagement is going to be web. If you can get into web application penetration testing, then you are likely golden :) Do not freak out about learning the newest and greatest tech with web apps; most frameworks have the same issues with their own special caveats. From there, pick and choose what seems interesting to you! When I started at Security Innovation almost all of the experience was in web, with a little bit of an exposure to IoT. However, since then, I have had exposure to native client's, blockchain, mobile applications, hardware and IoT. The consultancy should allow you to learn lots of new things, which is one of the best parts of being a consultant :)

The Truth

I have yet to work on a project where I knew the tech stack being used before starting the engagement. This sounds absolutely horrifying! However, this does not matter; I have been told this at my job over and over again. What does matter is that you are a fast learner. Furthermore, can you pick up the flow of this new web framework? How about, do you know the common security issues that occur with this framework? At the end of the day, being a hacker is not about understanding how a particular framework works; being a hacker it is a mindset. Once you understand the frameworks common issues, start to use the hacker mindset to exploit this issues or common mis-practices!

The reason I mention this is because I understand a few web frameworks starting my job; I thought I needed to understand every web framework. This freaked me out! What I learned though, was that most of the web frameworks tend to be the same. Again: it also matters that you are a fast learner and have the hacker mindset. If you can do this, you'll thrive in your job as a security consultant :)

Communication

As a consultant, it is pretty obvious that being able to communicate with client's is important. However, I found out recently that this is everything.

Why?

If you find the craziest/biggest vulnerability but cannot explain the impact to the client, then it is pointless. Similarly, finding the bugs is important; something that is more important is being able to remediate the issues. If you cannot tell the client how to fix the vulnerability that was found, then the client is going to start panicking. Being able to communicate the issues found and how to fix them is the most important part of the job.

Audience and Levels

Imagine: You are sitting in a college classroom and this very distinguished professor just starts going off about a very complex math topic. The professor goes deeper, and deeper and deeper... Leading everyone in the dust. The professor knows what they were talking about but was unable to communicate it to the students... Now, does this help anyone? Being able to communicate at the client's level of expertise is quite important. This is also known as know your audience.

Sometimes, the PM (project manager) or CISO (Chief Information Security Officer) will be on the call, asking about the issues, but have no technical background at all. So, if information is being spat out to me about the complex SQLi that was found, they will be left in the dust. However, if the team has a security engineer on the team or a excited developer, then feel free to explain the technical details of the vulnerability. For me, trying to speak at several levels has been immensely difficult. Going from the business impact of a vulnerability to the technical details of the bug is not easy to do, but necessary for the job. The vulnerabilities found and the write-up are practically useless unless they are spoken at the correct level for the client's needs. Remember: You are there for the client's benefit, not to boost your own ego. The important item on the agenda is to ensure the client understands the issues at hand and what to do about it, as well as the business impact.

Scope

Defining the scope of a project seems like a trivial task but it is far from it! The amount of times that a team has asked "Can we add this?" to the project, once I have started, blows my mind. Most of the time, I just default these types of questions to my boss (thanks Zak!) The main issue with scope is the communication on what is in scope and what is not in scope.

Besides the trouble with teams redesigning the scope part way through a project, make sure to test the right application and make sure you make permissions. Recently, two physical pentesters from Coalfire got arrested because the scope was not defined correctly. The moral of the story: verify that the IPs, domains or APIs are correct to ensure you are attacking the right service. Otherwise, you may incur major legal consequences or have an angry boss for not testing the right application.

Technical Writing

Going back to the communication point: this is not just spoken language, it is also in the reports themselves.

To start with, grammar (and English) is hard to get correct. In fact, even though I will proofread this post 10 times there will be several spelling and grammatical issues in this. In a professional setting, most of these are not acceptable. The writing should convey the point perfectly, with near perfect grammar... This sounds harsh; but, at the end of the day, the client is simply paying for this report that you wrote. So, this being of the highest quality is very important.

Tips

Here are several technical writing tips I have learned along the way:

• Reuse, reuse and reuse! There is a good chance that someone else has found a CSRF (Cross Site Request Forgery) vulnerability on an application before you and has decided to explain what CSRF is. So, why not just reuse their explanation? Of course, read through, make sure it applies and edit any grammar or outdated aspects of it.
• Proofreading is immensely important; take time to read over the report several times before handing it over to the client. When proofreading there are a plethora of items to worry about: Conveying the point correctly, pictures/visuals look nice, grammar/spelling are correct... A very large array of things to consider, which leads us to the next point:
• Someone else should read the report. At Security Innovation, before a report goes out, at least two people must review a report. By getting a second pair of eyes on the report more issues are likely to be found.
• Review the template. At Security Innovation, we reuse a fair amount of the reports that have been previously made with a templating system. I have been bitten in the butt an incredible amount of times on issues with the usage of words such as 'was' versus 'were' with templates. Or, fillers for the templates, such as the company name, not fitting into sentences just right. Even though the templating is very nice, ensure to read every section, especially the evil pre-filled in sections.

To be fairly frank, my technical writing skills are okay, at best. However, the more I read reports, the better I am at conveying my points to the client's. This skill will take some time to develop.

Note Taking

How hard could notetaking be? As I have learned, documenting everything is very important for an engagement. I have seen bugs occur once then disappear into the darkness... If the input is recorded and screenshots are taken, then there is a record of the issue, allowing for a problem report or further investigation.

What is exactly supposed to be noted? Obviously, vulnerabilities that are found. However, what about weird behavior? Quirks about the application? Anything that you feel is interesting should included in your note taking. I like to take the rule of thumb that "If it is not written down, it does not exist.". With this mentality, you will document everything you need.

Why should all things be written down? sometimes the website is really secure! In this situation, as a penetration tester, you cannot just say "Good job" then move on. Instead a test plan with the coverage of the application is needed. If you took good notes on how you tested something with what inputs, then you will be fine. Otherwise, writing the report is not going to be a good time. Additionally, during the retest of the application or on a client question, there is a need to pull old information (even months later). By recording as much as possible, you will be able to get back the information that you once knew! Besides the reasons above, documenting helps you remember things better and allows you to see the bigger picture. Please take good and detailed notes! :)

Best For Last

In a previous life (as a college student) I had to scratch and claw to get funding from the school in order for my buddies and I to go to DEFCON. Now, my company gives me a professional development budget. Even with this, if I am speaking at a conference, or we are trying to get into a particularly market, there is a good chance that the company will pay for me to go, outside of my professional development budget. In 3 months, I have attended DEFCON and TruffleCon with no out-of-pocket cost. For the rest of the year: Security Innovation will pay for me to attend ToorCon 2019 and potentially a blockchain week in San Francisco, with two conferences called Epicenter and CESC.

Besides the budget, Security Innovation, like a large portion of consultancies, has paid research time. So, you think that this smart lock is interesting? Take a look at it for a week or so! Or, this new IoT protocol looks cool? Let's spend some time looking at ZWave or something else. Being able to play around with new tech or look at new things is a really awesome opportunity to expand the skill set.

Why the Budget and Research Time?

At the end of the day, both of these benefit the company and the individual person. From the company's perspective, the consultants are at the top of the game, learning the newest and greatest techniques for hacking. This makes the marketing team and the sales people much better at their job, considering how expert the employees of the company look if research comes out or they speak at a conference. Additionally, getting the name of the company out in the open, by attending conferences and networking is helpful. This is very valuable for the company because this brings in new client's for penetration tests(making the company profitable).

From the employees perspective, it is obvious why all of this is beneficial, but is still great to talk about. When talking about conferences: instead of paying 1.5K to go to DEFCON, out of pocket, the company pays for the experience. From the conference, you hopefully learn an incredible amount and make professional contacts. Not having to worry about costs in order to take online courses, attend conferences or workshops is an awesome thing to have. This allows you to freely learn and develop in whatever areas you want, with very few limitations. With the paid research time: this feels like the hacking done in the basement, for fun. Just spend some time learning something interesting or hacking on something that has nothing to do with the company. This gives us the ability to learn awesome things but allows you to follow the curiosity that likely got you labeled as a hacker in the first place.

Conclusion

Starting a career as a security consultant has been like living the dream! I am surrounded by incredibly smart people to learn from and get paid to hack; what else is there to life!? In all seriousness though, I hope that this brief glimpse into the life as a security consultant has been helpful for people trying to get into this role. ❤️

If anyone has questions or wants to chat more, then feel free to send an email to me. Yes, I actually will respond! The email is in the footer of the website in a link. Cheers, Maxwell Dulin (ꓘ).