Viewing entries tagged

Infosec reading list 2019

Infosec reading list 2019

I got some great feedback from people at meetups and conferences that my reading list for 2018 was very helpful for them and asked I do another one this year. So here it is!

Last year had a heavy focus on everything  related to my day job in appsec. This time around I am going to pick from a wide range of security topics that interest me outside my usual focus of application security and security analyst kind of reading.

The most important theme I noted in the books I picked out for 2019 show my leanings and interests towards better understanding offensive security especially red team and attack simulation.

This is primarily because I want to become become a better defender and start to think about better joint exercises and collaboration with both the red and the the blue team might look like.

Im looking to get a much better understanding of red team tactics and how the engagements play out. Typically to date I have been assisting clients in scoping and remediation of red team engagements without having eyes on a deeper understanding of how the engagements play out I think its much harder for a defender like me to get the best value working with both teams.

Same objectives as with the The Hacker Playbook above. More red team reading :)

This was a recommendation from Amazon while I was looking at threat modelling books earlier last year. Often in threat modelling training I call attention to the mix of internal versus the external threats we must consider but feel like I might not be giving enough attention to the malicious insider threat element. I think this will help me think about the way I communicate insider threats to the people I am running threat modelling workshops with.

This is purely for pleasure, I had a quick hunt around for some reading on the Dark Hotel APT but couldn’t find anything that took my interest.

Along similar lines was this on Stuxnet. I remember following along as best I could on social media and infosec news when this was happening but this seems like it will take my understands of the event up a notch. Its going to be a fun read!

Again another book for pleasure. I am quite interested to know the history behind the Pinkertons and this is where I am going to start.

The description from Amazon covers it best:

The true story of Kate Warne and the other women who served as Pinkertons, fulfilling the adage, “Well-behaved Women Seldom Make History.”

Most students of the Old West and American law enforcement history know the story of the notorious and ruthless Pinkerton Detective Agency and the legends behind their role in establishing the Secret Service and tangling with Old West Outlaws. But the true story of Kate Warne, an operative of the Pinkerton Agency and the first woman detective in America—and the stories of the other women who served their country as part of the storied crew of crime fighters—are not well known. For the first time, the stories of these intrepid women are collected here and richly illustrated throughout with numerous historical photographs. From Kate Warne’s probable affair with Allan Pinkerton, and her part in saving the life of Abraham Lincoln in 1861 to the lives and careers of the other women who broke out of the Cult of True Womanhood in pursuit of justice, these true stories add another dimension to our understanding of American history.

I learned about Joe Navarro when I was an avid and regular tournament poker player looking to get an edge on reading body language and people.

I read several of his books and spotted this, I am going to read it and see how it potentially supplements the books I read last year on social engineering.

I read Robert Cialdini Influence: The Psychology of Persuasion last year and found it a real eye opener. Especially stacked with the other books I was reading on social engineering at the time.

Drift into Failure
By Sidney Dekker

I have referenced Sidney Dekker in previous engineering culture blog posts around blameless post mortems and just and restorative engineering cultures.

A deeper understanding of failure seems like an absolute no brainer for anyone building and trying to secure complex systems.

A very kind and thoughtful present from my twitter #HackerSecretSanta this year from @keithrozario. I feel like the infosec world is lagging a bit culturally behind our SRE and ops friends. I want to build the best bridges I can with these teams and part of doing that is ensuring I continue my education on Devops culture.

Very interested to hear about the books you read over the break and what you plan on reading in 2019. Feel free to reach out and e-mail form the contact page or hit me up on twitter @SparkleOps.

Caring for our pen tester friends

Caring for our pen tester friends

As an Application Security Specialist,  part of my role is to help teams with engagements ensuring they get a well considered and executed penetration test. Its important teams can not only understand the report findings but also learn from them and roll those learnings into their coding standards and come back stronger for the next audit showing their pen testers their real value has been understood. For this you need run the right testing first and that doesnt happen the real value is lost.

I have worked with engineering teams who have a reasonable level of security maturity and other teams who are just starting out on their journey in writing more secure code.

It struck me one day that both high and low maturity level teams really struggle with working closely with external penetration testers and in running a good penetration testing engagement.

I started to think about what was common across all the teams I have worked with and what could be the problem, and looked a bit into my own past life as a QA tester for answers.

I figured out what it was one day when I was thinking about a particular engagement I was doing testing some gas power-plant infrastructure stuff for a client remotely. I shipped a build to them with the ultimate confidence our engineers have provided  excellent software that both met the specification and was robust and my testing was solid evidence this was the case.

This was back in around 2007 where the way of producing software where I worked was the waterfall methodology. As a QA test engineer I was not really involved in planning, system design and very little in development.

Testers would instead be brought in at the very end of the project to test as much as possible and triage the issues at close out of testing in the hopes they could sign off a build and drop it into the clients user acceptance testing environment for their review.

Without all the right context I had tested to the spec and done some fantastic automation and performance testing. Based on my understanding from the spec I thought we had done a great job. I had almost completely perfect traceability and test evidence in the reporting to back it up.

Sadly we had missed several very important issues which showed up instantly and lead to a rather intense call with the client not long after pushing a build to their user acceptance testing environment.

It turned out while I had exceptionally great coverage of the specification and done well considered exploratory testing I was not an expert in gas networks and accordingly had missed some pretty critical issues.

It was a matter of context handover. The client had never worked with a professional QA tester before and didn’t understand really what I did and what I needed to be given in order to go on doing well in testing their system. I was also offsite so not really part of the internal team that was building things from their end.

Missing the kinds of things I did was entirely reasonable given this and to course correct the client made up a package of documentation, got me some business and technical support contacts and ran some peer testing sessions with me that completely fixed this.

Much later on in my software QA career and having been part of high performing agile teams who were shipping to production 10+ times a day I knew one of the many key elements that helped these teams perform building great software at such a cadence was having fast feedback loops and con conversations throughout everything they do. It was all about sharing and understand each others context.

Yet despite all the evidence pointing to successful engineering teams are those teams working much closer together across the disciplines and having especially QA and Security ‘shifting left’ throughout the entire SDLC , we are still doing security right at then end.

Like its waterfall all over again? Are we throwing a build over the fence to penetration testers offsite somewhere and asking them “Did we build this securely?”. It certainly seems so and I feel their frustrations mirror my own during my days of testing software built that waterfall style.

I have seen how much this is damaging for both the engineers / defenders and the penetration testers. The context is not handed over as well as it could be and the penetration testers aren’t always getting the level of support they need to execute a great engagement.

I set out a few years ago to start fixing this and have written this post (and have done a few conference talks) to help share what I learned help close these gaps and make life better for both teams.

Understanding the engineers perspective on pen tests

Firstly id like to talk about one of the most significant gaps between engineering teams and penetration testers. Often being in two different locations and handovers done via short calls and email both teams do not get the opportunity to have a well considered / meaningful hangover to understand each others needs.

It feels like the pen testing engagements are never forecast and outlined to the people building the software, especially their need and to be ready and supportive of penetration testers. The pen test  ‘sneaks up’ on engineering teams and before the engagement its always a mad rush to assemble the minimum pre testing requirements while also rushing to meet sprint deadlines and ship.

Engineers have often never been told what happens during penetration testing and do not understand the kind of context and support that would give pen testers the right context and information to execute your best testing.

Further to this some teams have a certain fear or anxiety around their work being audited by a security professional. Mostly likely because of the potential fallout and delays created by receiving a report with critical finds. That and in many causes the engineers are facing an audit on a skill set they most likely have received minimal to no training on.

It results in engineers not having the headspace or inclination to do a great job to handing over the penetration testers.

Often the result is a penetration test thats not sufficiently scoped or supported and everything suffers from execution to the reporting and the remediation.

Penetration testers trust me teams do struggle to work with you and understand how to best support you.

If you can respect this and really help them with what you need they will start to understand you are a teammate who they can work to ship a secure build together and not something to be fearful of.

Engineers and defenders, if the penetration testers get more involved you need to welcome the penetration testers into your team and support them every step of they way.

So how have I helped teams despite being often seperate make this stuff work better?

Scoping the engagement

  • Make the best use of a kick off call. Have engineers and QA people especially be available to walk through the application and requirements on a brief call with the penetration testers. A screen sharing sessions can work really and help both side consider some potential pain point to investigate further.

  • Lets get good at asking each other leading questions  

    • “What are the most important aspects of this system”

    • “What are the first things you’d attack in a system like this ?”

    • Then perhaps talk test approach, “Anything else I should look at?”

  • Sense check both teams have a mutual understanding of both the business as much as the technical elements of what you are trying to release

  • Non standard penetration testing engagements are ok! If your building a risky feature or something new with lots of unknowns why not ask for a split engagement where a code and design review happens at 20% complete? Work with your engagement manager to scope the test that makes sense not just testing at the end.

Can you have onsite testing?

This is one of the most effective ways I have helped teams fearful or new to penetration testing overcome this and get a good handover of context done at the same time. Any expense on flights and accommodation pays for itself 10 times over because

  • Especially if teams are new to penetration tests or struggling they will begin to understand the aims and needs of penetration testers and start to build a good relationship with them as team mates.

  • The most effective place to have operations, technical and business support is by being in the team building the software.

  • Fast Q&A / feedback loops as testing is being executed for both teams.

Know testing is coming and build the pre testing requirements early

Book and socialise the penetration testing well in advance, even consider adding it as a calendar item for the team members so they are mindful this is an activity they need to support and be involved in making a success of.

Have the team build out a well considered documentation package as part of pre testing requirements your Penetration testers ask for. Include anything that helps them understand what you have built. Examples include:

  • Network and component diagrams, A good overview of the environments

  • Solution architectures and specification documents

  • Early source code and issue tracking access

  • Early access to the test / staging environment

  • Two sets of testing credentials for every type of system user. Ensure they users are not touched by other employees in your business during the testing

  • Test scripts

Support each other to run a great engagement

To run a great engagement the teams should commit to supporting each other.

  • Engineering leads should specify a point of contact who will ensure they have business, dev, QA and Ops people on stand by

  • Make it your priority to  unblock penetration testers during engagement if they are missing context or locked out / are missing access

  • Penetration testers should for longer engagements make sure they check in with the teams. Especially if there is a high or critical find which is going to impact delivery or worse in known to be in production. 

Make the time for remediation and involve the penetration testers

Time for remediation needs to be budgeted for and engineering teams need to be taking advantage of any post testing review and regression testing activities on offer from the penetration testers. Dont be afraid of the report findings, get their help to understand them and improve the coding standards and education in your team to come back stronger for the next penetration test.

  • Engineering teams must defend the right to make changes to ship secure product. Put all finds into tickets and make a commitment to address them in order of risk.

  • Use the provided opportunity to talk through finds and fix approaches with the penetration testers

  • Developers participate in regression testing / code walkthroughs if they can.


The most painful thing for me as an Application Security specialist and no doubt our penetration testers is seeing different teams in the same company make the same mistakes. To show Penetration testers you are able to realise their true value to you beyond just doing another engagement and come back stronger next time.

Dont lock up the Penetration testing reports. While these are not for everyone in the business to see I encourage the technical report be shared across all engineering teams and ops / SRE teams too.

Applaud quickly recovering from and remediating issues just as much as not having them in the first place. While a clean test report is nice when you have finds you fix you are learning.

Track back report findings to support articles and entries in your coding standards. Help the engineers get all the support they need to be educated and not repeat history.

I hope these ideas can help you and your teams work closer with external pen testers. I will have a follow up blog post containing the YouTube video of the conference talk that supports this post in due course. 

As always id love to hear your thoughts and any ideas you have be it from the engineering side or as a penetration tester. I feel we must get things working closer so both teams have a much better experience and deeper learning.

Best way to do this is to reach out to me on twitter @sparkleOps.


Podcast - Penetration Testing

Podcast - Penetration Testing

I was super pleased to be invited back to the Ministry of testing podcast ‘Super Testing Bros’ with James @JamesEspie & Dan @DanielBarrowNZ .

I’ve been doing some conference talks here in New Zealand and in Australia about removing the common misunderstandings and roadblocks I see defenders and engineering teams have working with external penetration testers and getting these teams working tighter.

James and Dan asked me if id like to have a bit of a more general chat about penetration testing with a bit of a QA focus I was happy to oblige (Show link).

Generally on the show we cover off:

  • What do you mean by penetration testing? What should it cover?

  • Can I do it myself? What is the advantage of an external pen tester?

  • What should I do to prepare / make the best of a penetration test?

  • What kind of things can I do to support our external security testers? Especially how do we handover the right context?

  • I want to learn more about penetration testing or become a pen tester, where do I turn?

  • How to choose a penetration testing company, should you use the same one every time or rotate?

  • How do your build a productive long term relationship with your external penetration testers.

I hope you all enjoy the show and it helps understanding penetration testing and give you some ideas as to how you can work tighter with penetration testers.

As always you’re welcome to send me an e-mail or chat to me on twitter (@SparkleOps ) if you have ideas you’d like to share or feedback.

Security BSides Perth

Security BSides Perth

Super proud to announce I’m heading to Perth later this year to talk at the Security BSides Perth conference about getting closer collaboration between defenders, engineers and external security testers. The talk is entitled "Caring for our pen tester friends”.


Quality assurance teams are becoming more context driven and collaborative. QA Testers are now needed from design through to supporting their applications into production.

Yet we still ask external security testers to test our applications engaging them at the end just before we ship to production. Often armed with very little handover we ask them “Did we built it securely?”.

I see a big gap between external security testers and development teams, its making life hard for both teams. I also see the damage it does to good security testing. Its time to bring these two team closer together and start take better care of our pen tester friends.

This talk covers advice for both engineering teams and their external penetration testers on collaborating more, ensuring the right context is exchanged and the teams work together for better security testing outcomes.

Looking forward to it and all the other talks released so far. Its going to be an outstanding weekend. The full line up is posted here.

If your coming along do come say hi :) 

NZ OWASP Day 2018

NZ OWASP Day 2018

Hey everyone, wanting to give a bit of signal boost to the OWASP NZ day next week.

OWASP NZ day is a free day of information security talks and workshops with some excellent speakers from all across the New Zealand tech and information security communities. OWASP NZ day is being run on the 5th of February at Auckland University in the Auckland CBD area.

Registrations are now open and you can secure a ticket by heading over the to conference page.

OWASP days are a great chance for people in all roles and levels of experience to learn more about a wide range of topics in information security. OWASP is not just a day for devs or security professionals. Project managers, agile coaches, designers, testers and everyone in between can get some value coming along (and asking questions!)

We have an amazing security and tech community in New Zealand who love their craft and love sharing with and teaching others. With a more diverse range of folks in other non security  roles turning up and asking questions it helps infosec people think and reflect about how we might better help work with and secure the people we work with. Its win win. 

If you know someone who is shy or unsure if this is for them, encourage them to come! 

You can review the list of speakers here. Hope to see you there ! 

Infosec reading list 2018

Infosec reading list 2018

One of my goals for 2018 was to read a wider range of books for my professional development and I have set myself a target of at least 10 books i'd like to have read before the year is out. Then blog about my learnings from each book here. 

Below is my hit list and I have put a little something about each as to why I picked it.  

Agile Application Security: Enabling Security in a Continuous Delivery Pipeline
By Laura Bell, Michael Brunton-Spall, Rich Smith, Jim Bird

This year I am starting a new role as an Application Security Specialist where I have been hired to assist development teams build security into their agile development process. I believe this will give me excellent foundation to really know im working on the right initiatives with our software teams.  

Im working with agile teams to run STRIDE threat modeling sessions with the aim to better understand the security objectives of their applications and design out some potential flaws early rather than having penetration testers find them at the end.

The first cut of this framework I did I got a lot of help looking at slides and conference talks from Adam so this book  was a natural choice to get some learnings and greater understanding on the topic. 

This was one of a few recommendations I took from the Red team blog - Red teamers bookshelf. Im hoping this will assist me in running blameless post mortems with teams and in my own reflections throughout the year. 

DFIR is a subject I enjoy learning about. In 2017 I spent a quite a bit of time reading articles and exploring the fantastic DFIR training site by Brett Shavers  site and reading the O'reilly defensive security handbook. This feels like a great logical next step. 

The next few are all around social engineering and the human element of security. Last year I started with Social engineering - The art of human hacking by Chris Hadnagy. I absolutely loved it and cant wait to move on to this next book.  

One of my mentors suggested that if im going to read most of Chris Hadnagy's books I should look to get an alternative perspective and Kevin Mitnick would be a good way to round out my reading here. 

More reading under the social engineering umbrella. Another recommendation from the  Red team blog - Red teamers bookshelf.

Another from  Red team blog - Red teamers bookshelf :) 

I want to continue learning and understanding Devops culture and exploring the avenues for collaboration between security and SRE/ops teams. I know this came recommended from SRE engineers who read it at my last company. 

Lastly the Phoenix Project, another book which comes as highly recommended from the SRE lead at my previous job. I've decided to re-read this as it been a while and found it have me immense value the first time through. Again it’s good to think about how you and your security team relate and function with in the rest of your business. 

Whats on your reading list for 2018? As always keen to continue the conversation on twitter @SparkleOps.

Docusign breached - Account emails used for phishing attacks

Docusign breached - Account emails used for phishing attacks

DocuSign have confirmed a breach where according to their forensics attackers gained access to one of systems enabling them to harvest customers email addresses and then use them to launch phishing attacks. 

Brian Krebs has done an excellent write up here

If regardless of  you are a DocuSign customer or not you will want to brief your IT, operations and customer support people to be alert for inbound phishing e-mails to staff and be potentially also be ready to field reports from your customers and any 3rd parties you deal with that may be receiving these malicious e-mails. 

Now is an excellent time to also send a security awareness message out to the rest of your business that details some short and concise advice for your users to report anything they get to the right people running incident response. 

Wannacry ransomware outbreak - Update

Wannacry ransomware outbreak - Update

A few updates as things have unfolded further over the weekend. My original post when Wannacry  aka wcry ransomware first dropped is here.

Firstly and mostly importantly lots of critical infrastructure, hospitals and telcos which have legacy Windows 8 and XP machines are getting emergency support from Microsoft. Bravo Microsoft this is a great step to help defenders mitigate this threat.

Microsoft have also released this  customer guidance 

If you run these systems in production I have the direct links here thanks to this posting from Threat Post

Download English language security updates: Windows Server 2003 SP2 x64Windows Server 2003 SP2 x86, Windows XP SP2 x64Windows XP SP3 x86Windows XP Embedded SP3 x86Windows 8 x86, Windows 8 x64

Download localized language security updates: Windows Server 2003 SP2 x64Windows Server 2003 SP2 x86Windows XP SP2 x64Windows XP SP3 x86Windows XP Embedded SP3 x86Windows 8 x86Windows 8 x64

It seems the best mitigation is patching as soon as practically possible. If offlining or patching a machine is not an option then disabling SMB v1 is the next best thing.

Dont forget your change control and testing though. Nothing worse than accidentally offlining your business in the name of keeping it safe from potential threats.

Dont expect Wannacry to be a one off. Its exploiting a serious windows vulnerability and the chatter I see from security researchers I trust suggest its trivial to repackage and launch additional waves of attacks. We have already seen a wcry 2.0 version with the kill switch the original iteration had flagged off. 

Im following these sources  to help me follow this incident and ensure I have the right information in front of me to know our response is solid:

Thats all for now. My thoughts are with everyone incident responding to this. Its going to be a very rough week.

Wannacry Ransomware outbreak

Wannacry Ransomware outbreak

Woken up this morning to hear there has been a significant outbreak of ransomware known as Wannacry hitting windows machines which haven't applied the MS17-010 patch .

Ive copied the executive summary in the gist linked below as it perfectly contains the needs to know on this (credit to the rain-1 who stood this up). 

  • Virus Name: WannaCrypt, WannaCry, WanaCrypt0r, WCrypt, WCRY
  • Vector: All Windows versions before Windows 10 are vulnerable if not patched for MS-17-010. It uses EternalBlue MS17-010 to propagate.
  • Ransom: between $300 to $600. There is code to 'rm' (delete) files in the virus. Seems to reset if the virus crashes.
  • Backdooring: The worm loops through every RDP session on a system to run the ransomware as that user. It also installs the DOUBLEPULSAR backdoor. (source: malwarebytes)
  • Infections: NHS (uk), Telefonica (spain), FedEx (us), University of Waterloo (us), Russia interior ministry & Megafon (russia), Сбера bank (russia), Shaheen Airlines (india, claimed on twitter), Train station (germany), Neustadt station (germany)
  • Kill switch: If the website is up the virus exits instead of infecting the host. (source: malwarebytes). This domain has been sinkholed, stopping the spread of the worm.

Im following these sources  to help me follow this incident and ensure I have the right information in front of me to know our response is solid:

So its time to help support your friends and family ensure thier older windows machines are current with their patching and if your in tech, read up and share with our IT departments, SRE/ops folks to ensure patching is rolled out across your fleet of windows machines. 

LastPass exploits and feeling vulnerable

LastPass exploits and feeling vulnerable

I wanted to talk about the recent LastPass password manager exploits reported by @taviso and the negative perceptions it may create for LastPass as a password manager for its users. 

Its likely people who don't live and breathe the world of software and security see exploit reports like these and without context are left feeling their security tools are leaving them vulnerable.

Vulnerability - 'The quality or state of being exposed to the possibility of being attacked or harmed.'

I think it's important to talk to people about security flaws, the responsible discourse process and how the efforts put in by researchers like @taviso are of real value improving the security tools like LastPass. 

Password managers like LastPass are now an absolute essential for both home and business users. The DBIR data breach investigations report produced by Verizon's enterprise security team each year shows us that still one of the leading factors in users accounts being breached was poor password management and lack of 2FA being implemented.

These breaches were likely not the result of a highly sophisticated technical attack but attackers taking advantage of what is essentially low hanging security fruit. All of which can be mitigated if users are educated on use of a password manager and 2FA. 

But if the password manager they use is being reported as wide open to being exploited and their passwords stolen of what use is it?  Well thats the issue, The discussion and reporting surrounding these exploits walks right past some very important considerations and context users needed to make a judgement call on how vulnerable they really are. 

So how do we address some of the typical concerns and put things into proper context for our people?

We want to start with the possible misconception having security flaws reported is a huge failing on LastPass's account and we should all be switching to another password manager product to continue being safe. 

Its important to explain to users that all software has bugs and security faults and that its unlikely another companies password managers product is free from similar such issues. While companies will conduct their own testing and engage 3rd party security testers to review their products things can still get missed.  

Its follows then that we should  also aim to spend some time explaining the work security researchers do what a responsible disclosure process looks like. When issues are disclosed to vendors in this manner by researchers users are not being made instantly vulnerable to the exploit but instead the researcher is working with the vendor so they have an opportunity to fix the issues and push a fix to users. This is the case with the exploits been reported to LastPass there is nothing malicious going on that places them at risk.  

What will help people determine if they are at risk is knowing how we expect vendors to behave during such a disclosure. Vendors who are transparent about confirming the issue and quickly turning around a fix like LastPass has done should help users gain confidence in the software products and the security maturity of the vendor. 

Vendors who are not communicative, take significantly longer than the grace period to turn around fixes or respond with threats of legal action to a responsible disclosure are more likely to have a product or service that isn't being well managed with a mature security program and this is what is more likely to place them and their accounts at risk. 

Armed with a bit of education around responsible disclosures and some detail around the response from LastPass I'm confident in telling my users LastPass still provides them the protection they need to be safe at work and at home. 

While the LastPass exploits reports are still fresh and in the news its a great time to reach out to your users with a security awareness message on all of the above and provide that context that I feel is often missing when things like this happen. 

Additionally in your messaging explain that if passwords ever are compromised the second layer of protection they have in 2FA is what mitigates this if something does go terribly wrong. Help them set it up if they don't have it turned on.

Perhaps also consider showing them the haveibeenpwned service run by @troyhunt so they know if sites with no 2FA protection are breached they can quickly go and generate a new strong password before someone malicious can compromise their accounts. 

Our willingness to provide education and support in making these tools work and putting the risks in the right context and perspective when they arise will really help users feel a lot less exposed and vulnerable. 

Interested to hear your thoughts, hit me up on twitter @SparkleOps .