Ask Lesley InfoSec Advice Column: 2017-03-16

This week, I address some burning questions about education and training.  As always, submit your problems here!

Dear Lesley,

Let’s cut to the chase. I hate coding. I don’t enjoy building things from scratch. I do, however, love taking things apart, and would probably be able to learn to code if I started in that direction.

I currently work as a Linux sysadmin in the web industry, with a couple certs (and 4 years) under my belt so far. I love infosec and want to move in that direction, but I have no idea where to start, given my utter distaste for traditional methods to teach coding.
Do I just… download some arbitrary code and take it apart? That seems like a horribly insecure idea, but I’m just not sure where to start. I also tend to have serious issues with confidence in everything, especially tech. Please help! ”    

– Flustered and floundering

Dear Flustered,

I don’t like coding, either. It’s actually not uncommon in infosec – we tend to like rapidly changing environments instead of the routine patience involved in coding. I’ve spoken to many ex-programmers and ex-CS students who agreed.

I see two routes you can go if you think anything like me:

  1. The scripting route: Many, many blue team and red team tools are Python and Ruby based, and many of them are extensible by design. Pick offensive or defensive security, then choose a tool set in one of these common languages that interests you. (For me, it was the Volatility framework). Take apart a few existing scripts and see how they function in real life. Then pick some interesting feature to add in your own script. This won’t necessarily teach you how to write a stellar production application, but for most security roles scripting is what you need.
  2. The reversing route. If analyzing malware piques your interest, that’s a great way to learn how software works all the way down to the assembly level. The intrigue can be a great motivator to learn. Definitely don’t pick commodity malware out today to analyze -it’s purposefully hard to reverse! Start with a book like Practical Malware Analysis or Malware Analyst’s cookbook that has detailed, step by step tutorials from the very basics. Learning how to take something apart can be a great way to learn how to put it together, and you’ll definitely figure out what fundamentals you need to brush up on on the way.

Dear Lesley,

Looking into the future…what would you guess would be the safest career path/area to focus on now in security, considering the growth in available off the shelf tools to get the jobs done. Would penetration tester still be needed for example in 10-20 years time?  

–  Spinner.

Dear Spinner,

First off, no guarantees – I’m not clairvoyant. There definitely is something of an infosec bubble as more people enter degree programs. However, there’s a caveat – being a great hacker is a personality trait, not a skill that can be taught academically. If you’re innovative and adaptable, I sincerely doubt you’ll have trouble finding work in that time frame.

In terms of automation, some tasks automate better than others. Unfortunately, the one that automates the best is the entry level security analyst gig. Merely passing the Security+ and being able to read and route SIEM events may not cut it in a couple years. You’ll need creativity and a broader skill set. More advanced defensive and offensive roles will require human attention for the foreseeable future because attackers innovate constantly. While a magic black box may pick up a new zero day, remediating and understanding the impact and additional factors is more complicated.

Security engineering continues to become more automated. The need for people to simply maintain static blocklists, signatures, or firewall rule sets will continue to decrease. Those jobs are trending towards more advanced SIEM and log aggregation management.

The jobs I see in the most demand with the least supply right now are malware reversing at an assembly level, threat intelligence with an actual political science or foreign studies background, and higher level exploit research (coupled with good business and communication skills).

Dear Lesley,

How does one begin exploring the world of sec without coming off as a script kiddie or just wanting to be an “edgy hacker”?     

– Careful but eager beaver

Dear Careful but Eager,

I’m really sad you feel that you have to ask that question, because merely asking it means you probably aren’t the type you’re concerned about. How do you know if you’re skidding it up? You enter commands into a hacking tool with no idea what they are doing, and much more importantly, no interest in knowing what they are doing. Being a good hacker has nothing to do with pwning stuff. It has to do with understanding how lots of stuff works and being able to manipulate that to your advantage.  (I should put that at the top of my blog in huge red letters!)

Imagine you’re a secret agent, needing to break into a vault. You can take one other person with you. Person 1 is another agent who has read a few books on how the vault works. Person 2 is the engineer who has been installing and maintaining the vaults for 30 years and has agreed to help you. Who do you pick? I’d pick the second person, who knows the system inside and out. I can teach her to sneak around a little and how to wear a disguise. Person 1 doesn’t know the foibles of the vault and only knows how to attack it the way the books said.

To summarize, you skid check is how many commands you enter in Kali or Sift or whatever without bothering to figure out what the heck you are doing. When you’re learning, the goal is understanding that, not getting a shell.

You shouldn’t care what you come off as. If you’re genuinely interested in learning, plenty of hackers will be willing to help you.

Dear Lesley,

(tl;dr at the very last line)

I am a novice who is looking to break into the field of security. Currently, I have received an offer to read a book (The Web Application Hacker’s Handbook) and participate in an assessment to show if I can perform the work necessary to do the job. Essentially, the assessment (from what I’ve gathered) is to assess the security of a vulnerable web application and then reverse a protocol.

Coming from a mathematics background with limited formal education in computer science and no formal education in networking, the book is hard to digest. I have setup pen test labs such as DVWA and WebGoat which I am practicing with and I have made surprisingly good progress in these labs. I’ve also learned a little bit about networking through much trial in error in setting these labs up in safe environments!

However, I fear that even if I pass the assessment, I will not be offered a position due to my lack of networking knowledge. I am aware of certifications such as OSCP and Security+ to bolster my background, but they suggest a solid understanding of networking before enrollment in the courses or studying for the examinations.

Do you have any recommendations on books/courses/certifications that would take an individual from zero-knowledge of networking to the suggested level of networking knowledge for these kinds of security certifications?

– Not a smart man

Dear Smart Man (I refuse, because it’s untrue!),

It really sounds like you’re doing everything right. You have correctly recognized that solid TCP/IP knowledge is really important in security. The lab is fab. But, you can do other things in that lab. Like take a step back from the security tools, and concentrate on the networking ones. How long have you spent in Wireshark, just observing and filtering through network traffic? Something just watching what’s going on and identifying common ports and protocols can be huge. What does opening a website look like, and why? What does a ping look like? What does it look like when a new computer is connected to the network?

Certs (and associated books)… There are a lot of options in network land. Network+ is okay for fundamentals and really cheap (although an inch deep and mile wide). WCNA is the Wireshark specific cert, but by nature teaches a pretty in-depth level of knowledge of reading packets. It’s also quite affordable. If you have 600 bucks and free time, I’d do both (in that order) and blow those folks out of the water with your resume. If you don’t have those resources, they give you some great study materials to start with.

There are endless good books and blogs on TCP/IP out there that will get you started and give you an understanding of the OSI model and common ports and protocols. Hands on experience in your lab or on your home network  is much more important.




Phishing Exercises, without the “Ish”

Much like open offices and outsourcing in business, information security is subject to trends. One you probably saw in your vendor spam folder over the past couple of years is phishing awareness exercises.

The premise sounds simple – phish your employees before the bad guys do, monitor how they respond, and react accordingly.  In reality, people’s experiences have been more complex. There’s not much middle ground in the discussion of phishing exercises. I see either glowing articles praising their merits (most of which are selling something), or bemused cynicism about them from security professionals. In my experience, there really can be benefits to running phishing test exercises in a sensible way, but many organizations are not implementing them in a sensible way, so they end up pretty worthless.

When you’re setting up a phishing test program, you have the option of developing your own phishing exercise infrastructure and metrics collection toolkit, combining open source solutions like King Phisher or (SET), or purchasing one of many available commercial solutions. I won’t advocate for one brand over another in this blog – most will work (in the right configuration and conditions). A similar set of concerns exist, whether you develop a deployment and metrics solution, or you buy a commercial solution in a box. Let’s discuss how any and all of these tools are being used incorrectly.


Before spending money, or implementing anything

Develop a clear goal for your program with your senior leadership fully involved. This goal should not be, “stop employees from clicking on phishing messages”. That’s simply unattainable. Yeah, you want that number to decrease, but even top security professionals have fallen for well-crafted phishing messages. People click on things when they’re busy and distracted, and it theoretically only takes one compromised host to breach a network. A real attacker only has to get that one, inattentive click. If your senior management measures your success by phishing clicks reaching zero, you’ll ultimately find yourself dumbing down campaigns to look more successful. This won’t do anybody any favors.

A more realistic goal is improving the quantity and speed of reporting of suspicious emails. Detecting phishing with tech is hard. Most organizations spend a great deal of money on modern solutions to catch and alert on phishing messages, and even those can be circumvented. Your last line of defense against phishing and social engineering is a good relationship with end users who will promptly tell you they are being attacked. While it takes only one phish to compromise a network, it takes only one prompt report to security to shut an attack down.

Next, you should bring your HR and Legal teams into the conversation and discuss anonymity. There is no room for gray area here. You will either conduct phishing exercises anonymously or you will not. If you conduct the phishing exercises anonymously, you must develop the program in a double blind way where even network security can’t practically retrieve the names of people who clicked. You’ll still see an overall view of the health of your organization, but nobody can be pressured to provide identifying data, even by angry executives.

If you choose to not conduct exercises anonymously, I recommend that you clearly document any repercussions for clicking, and ensure they are uniform across your organization. Otherwise, your exercises could easily become a public humiliation game or end in unequal punishment by managers, putting you in hot water with HR.


A carrot, instead of a stick

Regardless of if you conduct your exercises anonymously or not, you may decide to provide extra security training to people who click on your test phishes. Frankly, a lot of security awareness training is pretty awful, “death by PowerPoint” stuff. If your users can fly through every slide and kludge their way through your multiple choice test, chances are it’s a waste of time. Try to have some empathy for how an end user is feeling when they click on a test phish and are routed to a long, mandatory training. They’re embarrassed, frustrated, and it’s very possible they clicked because they were already frantically busy. In their minds, you aren’t helping – they feel like you tricked them. There’s now hostility in your relationship, not a willingness to help “the team” stop attackers.

If possible, in-person training is a great option (snack bribery highly encouraged). Offer a lunch and learn, or a social hour with IT security. Offer this in lieu of traditional web-based training, and have a conversation with your end users. People are statistically more inclined to help somebody they have met in person and feel some connection to. You want to try to make your phishing exercises a positive thing that people want to improve, not a negative thing that people subconsciously associate with punishment or embarrassment.

If training has to be computer-based, try to make it quick, effective, and interactive. This is a space where you may wish to spend some money to get something good quality and enjoyable.

Be clear about what you’re trying to accomplish with phishing exercises and why they are important to your organization. Ensure you give credit to people who report phishing and help your team improve more than you punish people who make genuine mistakes. It’s better to provide measures to protect victims and help them learn, rather than encourage them to circumvent your security team.


Who should you phish?

Establish the scope of your exercises. Must certain employees be exempt for legal reasons? Are multiple languages spoken in your organization which will require separate exercises? Will your exercises be conducted across global business hours and all shifts? Have you done some OSINT to generate a list of exposed users and email addresses that require special attention?

I highly advise against phishing everybody at once. The only things that travel faster than light in workplaces are rumors. Once one person realizes he or she has fallen for the phishing exercise, it’s nearly impossible to contain the “helpful warnings” to neighbors and friends. This is good, but won’t necessarily give you accurate metrics about individual performance.


Designing your phish

Security teams everywhere look forward to this part with glee. I must remind my blue team friends of a lesson that successful red teamers learn early in their careers: your job is not to “get” your target for the laughs. Your job is to educate your target and improve their security. You are on their team. Yes, you can phish nearly anybody with a well crafted message and insider knowledge. Conversely, you can produce excellent metrics by selecting an absurdly easy phish. Neither results in any significant security training.

Your phishing exercises are a scientific experiment, and a good experiment has as few variables as possible. The variables that do exist must be well quantified, and should include the difficulty of the phishing message, which is easier said than measured. Comparing clicks on an excellent phish with perfect grammar and a timely topic to one that applies to few employees and is written in poor English is apples to oranges. If you want to change the variable of phishing difficulty, do not change the variable of employee selection or time of day, and vice-versa.

If you’re having trouble with this, look to your phishing awareness training. Most commercial training programs list warning signs of a phish. When developing your messages, choose a specific number of these specific warning signs to include.


Avoiding phishing-related divorces, and other unpleasantness

Writing a phishing email seems fun and easy. You copy one you’ve seen in your filters, or use a common phishing theme, and send it out with a link or attachment, right?

Or not.

Bad guys have it a lot easier than us, as defenders and pen testers. Bad guys can emulate any public company or person they want in their phishing messages, and abuse any emotion. While we want to make test phishes as realistic as possible, there are good reasons why we have to put more thought into ours.

The reaction of a human being to a phishing email depends on a lot more factors than just their corporate security training. They’re also influenced by their outside security education, their biases and experiences with the content of the message, and their emotions. Imagine a phishing test email that uses the classic “payment received” scam, ostensibly from some real online payment firm. Some people will look at the phish, see it for what it is, and report it appropriately. Others will Google the payment provider and report the phish to them instead; a black eye (or even a blacklist) for your company. In a worst case scenario, an employee could receive the message and apply a personal context, forwarding it to their spouse as ‘proof’ they’re hiding money.

You must try to keep your phishing exercise contained. Remember, you are handling live lies. Not only could forwarding of your test message alter your metrics, but it could also result in more dire legal or ethical consequences if it should leave your network perimeter. Ensure you thoroughly prevent this, and clean up after your exercise as soon as possible once you’re done.