Mike Landeck’s talk from the ISC2 World Congress 2016 in Orlando on some of the more publicized breaches of 2016.
Mike Landeck’s talk from the ISC2 World Congress 2016 in Orlando on some of the more publicized breaches of 2016.
Giraffes can’t talk, but if they could they’d tell you they were tired. Really tired. You see, giraffes are so consumed with being on the lookout for predators they have evolved to only sleep for a few seconds at a time. They have to continually wake up and look for predators thus missing out on some of their basic requirements.
Ostriches, I suspect are much happier. They live an abyss of ignorance where at the first sign of a predator they can put their head in the sand and have nothing to worry.
As a Security manager, you don’t really have the luxury of being an ostrich. We are continually bombarded with an unpredictable amount of audit findings, intrusion detection alerts and vulnerabilities that have to be addressed within a set budget and headcount. The challenge is that finding will always happen at a faster rate than fixing giving you a never-ending list of top priorities. This pushing the rock up the hill can lead to job stress and burn-out.
Over the years I have developed some giraffe survival skills that I’d like to pass along to you folks new to security management:
(Cross posted to LinkedIn.com)
At a time when continuous integration is king and anyone with a web scanner is calling themselves a pen tester, OWASP’s Juice Shop project is a refreshing reminder of the need for creative, out of the box security testers in our software security assurance programs.
With the popularity of agile methodologies and devOps, lengthy software security assurance activities can slow things down. To counter this, lengthy DAST scanning and code reviews have given way to automated security testing. For identifying simple vulnerabilities such as cross-site scripting and SQL injection, this is a good solution and allows organizations to scale their efforts beyond the range of manual testing. However, automated assessment without strong security involvement in the design phase can leave such security flaws as logic errors and weaknesses in complex workflows dangerously undiscovered. In an industry that has tasted the cost-savings of security test automation, adding expensive manual assessments back in to the release process can be a hard sell. And then came OWASP’s Juice Shop.
I was approached by the author of Juice Shop, Björn Kimminich, to do a write-up on the OWASP project. To confess up front, I didn’t know much about his project and readied my scanners for what I thought would be a fun point and shoot session. However, during my initial inspection I XSS’d the search field and a banner popped up telling me that I had completed a challenge.
With a little more digging I found that the site contained an actual score board tracking what I and had not completed. My MLK weekend plans were now aborted and the obsessive security geek in my had taken over.
Fast-forward a lost weekend and a lot of Googling and I’m about ¾ths done with the challenges- which isn’t half bad for a middle-aged security exec. What is remarkable however, is that in spite of the fact there are 39 unique hacking challenges the majority of the exploitable flaws do not show up on a dynamic, authenticated scan! This is fairly serious considering some of these challenges include defrauding the Juice Shop out of money, taking over the admin account, and impersonating the Juice Shop’s CISO. None of these however were found by the several dynamic scanners I ran against the site.
So, what is my take-away from all this? Try running Juice Shop through your current assessment program and see how many of the findings your processes uncover. I suspect you’ll either be beefing up your security design reviews or adding manual pen testing back in to your process. Maybe even both…
The number of openings is limited so I need to act fast…
,Dear.. Need to earn a little extra cash? Want to work from home? You can earn up to $375 a week or more as an Online Mystery-Shopper. Our system is simple and produces great results. Here's how we do it: We work out what our online retailers need from you, the online mystery shopper. The best thing about online mystery shopping is its simplicity. Instead of spending millions of dollars in advertising their products and services, Online companies go directly to the consumer. Companies are able to improve their customer service through the feedback you provide for them. If you are interested,Email us the below details : 1. Full_Name: 2. Email: 3. Street : 4. City: 5. State : 6. ZIP_Code: 7. Phone: 8. Gender: 9. Birth-Year : All shoppers must be 18 or over All shoppers must live in and be a citizen of the United States. Unfortunately, we can only take on a limited number of applicants, so not everyone will be accepted. If you are accepted, congratulations and welcome to our company. Yours Sincerely, Shannon Calleja. @Copyright 2005 - 2016 All Rights Reserved.
Too many things wrong with this to list here. I think the worst part is the use of the name “Roman Rape” as the sender.
Don’t all kill the messenger at once but the sad truth is there are a growing number of organizations that are not seeing the ROI in pen testing and I’m afraid they have good reasons.
There is a concept in organizational behavior about there being two reasons for a culture’s behavior- the reason they give you when asked and the answer that is not verbalized.
When leaders are asked why they are decreasing their spending on pen testing the answers I am hearing sound very reasonable- the attack surface is too broad, the number of attack vectors has grown to an untestable number, etc etc. No argument here.
However, I would argue that there are also some other, probably bigger reasons that have a larger influence that do not get verbalized. In fact, I think there are six of them.
The security boom we’ve all been enjoying has created a huge need for security professionals. As a security professional I’m loving it. However, like all skills shortages there is a vacuum moving the bar for “senior level” down lower and lower. What was once considered an intermediate level tester is now considered a senior person.
This is a reality that has no good answer. Personally, I prefer to have testers who have their OSCP certification but with supply and demand this has become a luxury, not a baseline.
I find that the actual definition of what a pen test is has been evolving and some of that evolution seems to parallel the supply and demand issue. What we used to refer to as automated assessment tools have now become the pen test. Scanning a target with nmap, Nessus and Burp and pasting the results in to a template is not a pen test. There is certainly value in these activities as one of many parts of a holistic assessment but calling it a pen test has diluted the value of the term.
Pop quiz- name a recent major breach that didn’t involve a targeted email as the point of entry? Yea, me neither.
However, most pen test will have rules of engagement prohibiting spear phishing employees and the use of backdoors. I strongly suspect the perception of a pen test report would jump in value if it contained screenshots from the meterpreter session running on the CFO’s laptop while he transfers funds between banks. There are some really good reasons pen tests can’t mimic real life attacks but because of this their value is reduced.
Another aspect of pen testing that doesn’t match real life threats are the length of engagement. In real life attacks, the bad actors don’t have a time limit. They can spend months or even years on their target. In a pen test, the tester has a week or two to do his assessment and write up the findings. We can’t expect a team of testers to be able to cover all possible vectors in a few weeks.
Billable hours pay your bills but they don’t exactly light a fire under an analyst’s rear end. I’ve often wondered what an assessment would look like if the client set up a pen test like a bug bounty, providing the team incentives for what they found. When a team of bad actors operating out of Eastern Europe can retire after one big score and you have pen testers working for billable hours there is a motivation mismatch.
For a pen tester to do a great job they need to be able to follow where their findings and instincts take them. A “pen test by numbers” will appease a requirement but unless it’s done with passion and purpose it’s not going to be great.
Do I think pen testing is still valuable? Absolutely. But for all of the reasons above I think it is getting a bad rap. Disagree with me? I’d welcome your thoughts. @CyberSecOlogy #pentesting. Contact me via the form below:
Yesterday, Google Security Engineer Claudio Criscione released version 0.42 of the web scanner test application called Firing Range. The author of the test app describes Firing Range as “a Java application built on Google App Engine and contains a wide range of XSS…” They make the source available on github or there is a public website available for target practice.
At first glance, Firing Range looks sparse. However, those who don’t look past the landing page and launch a tool or two are not going to be able to appreciate the elegance of the test site. Firing Range is a unique and valuable addition to the web’s portfolio of test sites.
While the Hackazon test site provides what I have described as a “torture test” for scanners Firing Range is more of a “Rubik’s cube.” Most scanners will complete a test of Firing Range in well under an hour and nothing about the site is resource intensive or attempts to hide vulnerabilities from the test tool. Instead, Firing Range takes the opposite approach and focuses on completeness of the assessment. That is, every test page is directly available within the first two levels of the landing page and all the test pages are labeled for the target test. For example, all of the pages that test for reflective cross site scripting are available from the reflected cross site scripting page. This page is then broken in to clearly defined sections:
Firing Range on its own should not be considered a single source for testing a scanner (and I do not believe the author ever meant for it to be). However I believe that it will soon become a gold standard when assessing a scanner’s ability to detect and report on cross-site scripting.
At the recent “Security Summer Camp” in Vegas I got to chatting with a guy who was employed as an intermediate-level security analyst. As we discussed our backgrounds he reluctantly disclosed that he had been a former Info Sec executive. Doing my best to not pry I hinted about why an Exec chose to be an analyst fully expecting to hear that he missed having a technical role, something I struggle with frequently.
His story, however, had nothing to do with a need to return to the trenches. He had been responsible for security at a company that had a semi-famous breach. As he explained it, once his name had been tarnished by the breach he could not find anyone to take a chance on him. He referred to himself as “damaged goods.”
As a sad piece of short-sighted irony, after talking to him I can tell you there is no one who has thought more about breach prevention than he had. His perseverating on the incident in the months following gave him a remarkable insight that any organization with digital assets to protect could benefit from.
After we parted and went our separate ways it occurred to me that while we work hard to create incident response plans for our organizations we do little about an IR plan for our career should an incident leave our names tarnished.
While a termination may not necessarily constitute an incident, the weeks following this person’s termination clearly met the criteria. His initial assessment of the damage to his career was dire. He was losing LinkedIn contacts daily and his calls to his peers were not being returned. He had never planned for such an event and the incident and termination left him too beaten down to take much action. In essence, he had failed to have an incident response plan for his career.
Feeling isolated and shunned, he wanted to reach out to key contacts. However, with the intensity of building his career he failed to form friendships within the profession and had certainly never discussed this type of situation with any colleagues. In essence, he had failed to create his incident response team.
The interaction left me wondering- in Info Sec are we too quick to label someone as damaged goods once their organization has been breached? While we put plans in place to respond to reputational damage to our organizations do we also need plans for our own reputations? In this post-Google world should we think of ourselves more as brands than a workforce pool?
The story you have just read is mostly true. Some details were changed to protect the innocent.